- Marcar como novo
- Marcador
- Subscrever
- Silenciar
- Subscrever fonte RSS
- Destacar
- Imprimir
- Denunciar conteúdo inapropriado
My cpu is a i9-14900K I've exported the ek cert using the powershell commands
$a=Get-TpmEndorsementKeyInfo
$a.manufacturerCertificates|Export-Certificate -filepath "D:\Downloads\test.cer"
but it is a self signed certificate signed with the private ek, I've also tried computing the pub hash and using https://ekop.intel.com/ekcertservice/ but it returned
{"message":"Forbidden"}
I've noticed CN = CSME ADL PTT 01SVN but I have no idea where to find the certificate for this. How should I verify the certificate chain on the intel ptt ek certificate?
for example on AMD they have http://ftpm.amd.com/pki/aia/ and their ek cert comes with authority info that points to their certificate chain and easily verifiable.
- Marcar como novo
- Marcador
- Subscrever
- Silenciar
- Subscrever fonte RSS
- Destacar
- Imprimir
- Denunciar conteúdo inapropriado
Starting 11th gen core, Intel PTT Endorsement Keys are certified using the Intel ODCA (On Die Certificate Authority) and no longer through EK Online Provisioning server (EKOP).
In order to walk through the certification path, you will need to obtain the embedded intermediate CAs (EICA) as described in
TCG's EK Credential Profile section 2.2.1.5.2 "Handle Values for EK Certificate Chains".
The PTT's EKs are signed by the PTT EICA (as you saw "CSME ADL PTT 01SVN")
The PTT CA is signed by the CSME Kernel EICA, the Kernel EICA is signed by the CSME ROM EICA which finally contains an AIA URL to it's issuer as you used to..
As seen in the TCG EK Credential Profile, you will find the PTT, Kernel and ROM EICA in the NV range allocated for EK chain.
On windows you can use the optional tpmdiagnostics feature to read the embedded intermediate chain:
# Install TPM Diagnostic tool optional windows feature:
PS C:\> tpmtool oc add
# Check EICAs exists in NV:
PS C:\> tpmdiagnostics ekchainnv
# Read certificates as text (read all indices in chain range and stop when NV index is not defined, in your ADL device, 0x01c00101 should not be defined since the chain fit into one TPM NV index):
PS C:\> tpmdiagnostics ReadNVIndex 0x01c00100 > nv_0x01c00100.txt
PS C:\> tpmdiagnostics ReadNVIndex 0x01c00101 > nv_0x01c00101.txt
Note that the above will output the certificate chain (concatenated ROM || Kernel || PTT EICAs) in text and not in DER/PEM. and will need some hex editor to convert.
another option is to look in the registry under:
“HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement\IntermediateCACertStore\Certificates”
Please let me know if this information helps and if you have more questions
Link copiado
- « Anterior
-
- 1
- 2
- Próximo »
- Marcar como novo
- Marcador
- Subscrever
- Silenciar
- Subscrever fonte RSS
- Destacar
- Imprimir
- Denunciar conteúdo inapropriado
Thank you, Liranper, for this information!
I'll look into it and reply here if I encounter any issues.
Best regards
- Marcar como novo
- Marcador
- Subscrever
- Silenciar
- Subscrever fonte RSS
- Destacar
- Imprimir
- Denunciar conteúdo inapropriado
Thanks @liranper . Your examples cover Windows. But is there a suggested solution for Linux with any of the available TPM tools packages?
Update #1: After I asked, I figured out how to read the chain with tpm2-tools from the index you mentioned:
> tpm2_nvread -C o 0x01c00100 > ODCA_chain.der
WARN: Reading full size of the NV index
Now, that chain contains several concatenated certificates in DER. I can decode the first one in the chain (that happens to be CSME ADL ROM CA) or convert it to PEM using the OpenSSL conversion command. But how do I convert or decode the rest of the chain? DER binary certificates are not normally concatenated by simply being bundled together like PEM certificates. Even when looking with a HEX editor I don't know for sure where one certificate ends and another one begins. Is there a delimiter I could use? A specific offset?
Update #2: '30 82' seems to be a decoded delimiter. The problem is there are more of those than the certificates. I was able to manually extract the whole chain but need to find a way to do it programmatically. If you can point me to a less painful way of figuring out the certificate offsets within the NV index, that would be very helpful.
Thanks in advance.
- Marcar como novo
- Marcador
- Subscrever
- Silenciar
- Subscrever fonte RSS
- Destacar
- Imprimir
- Denunciar conteúdo inapropriado
Update #3. 3082 delimiter is followed by 2 bytes containing the size of the next certificate. So read that number of bytes + 4 (ROM CA certificate), then jump to the next offset, learn the next size, read that number of bytes + 4 (Kernel CA certificate), then repeat the process for the last certificate (PTT CA).
Intel should publish this procedure or provide a small utility to read the chain.
- Marcar como novo
- Marcador
- Subscrever
- Silenciar
- Subscrever fonte RSS
- Destacar
- Imprimir
- Denunciar conteúdo inapropriado
we are faster then Intel
https://github.com/mrwiora/intel-ek-dechainer/tree/master
hope this helps the one or other...
sidenote: luckily openssl does not care too much about the critical extensions obviously, but with golang I observed the exact same behaviour as @materye
Unhandled critical extensions found:
- OID: 2.5.29.17
x509: unhandled critical extension
- Marcar como novo
- Marcador
- Subscrever
- Silenciar
- Subscrever fonte RSS
- Destacar
- Imprimir
- Denunciar conteúdo inapropriado
I don't know if this is the best place, but i just wanted to inform you about a problem with the EK certificate. If this issue is already addressed then please just ignore this message.
CPU: Intel(R) Pentium(R) N6415 @ 1.20GHz
There is a problem regarding the EK certificate (not the chain). I extracted the EK certificate from the fTPM, which can be found here.
In Extension > extnID OBJECT IDENTIFIER 2.5.29.9 subjectDirectoryAttributes the value of critical BOOLEAN false is set,
this is the default value. According to the DER encoding specification (ITU-T X.690), section 11.5:
"The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value."
Due to this some cryptograhpy libraries will raise an error and reject loading the certificate. One of them being python cryptography.
It would be great if this information could be forwarded to the engineers and addressed in future releases.
Best regards,
Eugen Matery
- Marcar como novo
- Marcador
- Subscrever
- Silenciar
- Subscrever fonte RSS
- Destacar
- Imprimir
- Denunciar conteúdo inapropriado

- Subscrever fonte RSS
- Marcar tópico como novo
- Marcar tópico como lido
- Flutuar este Tópico para o utilizador atual
- Marcador
- Subscrever
- Página amigável para impressora
- « Anterior
-
- 1
- 2
- Próximo »