Use NV cert index as auth hierarchy for EK cert

This is the same approach tpm2_getekcertificate uses, with its
`TPM2_HANDLE_FLAGS_NV` flag.

The main impetus here is is ChromeOS's vtpm implementation[1], which
doesn't have a concept of an "owner" or "platform" password and expects
the NV index itself as the auth hierarchy. In either case, as this is
the same approach tpm2_getekcertificate uses this should provide a more
standard/common approach as opposed to relying on the owner password to
be empty.

Tested with both CrOS's vTPM and a real TPM on Debian.

b/258300352

[1]: https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform2/vtpm/commands/nv_read_command.cc;l=64-68;drc=1efd0c8f36050d56b8550354a4c7af925e44118a

attest/tpm.go

@@ -223,7 +223,10 @@ func intelEKURL(ekPub *rsa.PublicKey) string {
 }
 
 func readEKCertFromNVRAM20(tpm io.ReadWriter) (*x509.Certificate, error) {
-	ekCert, err := tpm2.NVReadEx(tpm, nvramCertIndex, tpm2.HandleOwner, "", 0)
+	// By passing nvramCertIndex as our auth handle we're using the NV index
+	// itself as the auth hierarchy, which is the same approach
+	// tpm2_getekcertificate takes.
+	ekCert, err := tpm2.NVReadEx(tpm, nvramCertIndex, nvramCertIndex, "", 0)
 	if err != nil {
 		return nil, fmt.Errorf("reading EK cert: %v", err)
 	}