Intel® Dynamic Application Loader (Intel® DAL) Developer Guide
Visible to Intel only — GUID: GUID-5217B969-66CF-45F0-ABA4-15D164DEA852
Visible to Intel only — GUID: GUID-5217B969-66CF-45F0-ABA4-15D164DEA852
SIGMA 1.1 Sample
This sample demonstrates how to enable an application running on the firmware securely to exchange symmetric keys with a remote party using Intel® Dynamic Application Loader (Intel® DAL).
This sample is applicable for API level 4 and above.
The SIGMA protocol sets up a secure session between an Intel® Enhanced Privacy ID (Intel® EPID) prover and verifier.
- A verifier can refer to different entities, such as a TRS-based host application, an Intel server, or an ISV key provisioning server.
- The prover is typically Intel hardware.
The SIGMA protocol is based on the Diffie-Hellman key exchange and uses the Intel EPID signing algorithm to authenticate the firmware to the remote party. Since the SIGMA protocol uses an Intel EPID signature, Intel EPID must be provisioned prior to using this class. For details, see the Intel EPID Provisioning Sample.
The basic SIGMA flow:
The components of the sample:
- Server: represents the remote party, the verifier, that needs to verify the platform identity.
- Host application: communicates with and transfers data back and forth between the server and TA.
- Trusted application: represents the Intel EPID prover that needs to prove that it is included in a valid Intel EPID group.
The trusted application generates identification messages to be sent to the server. The server processes and verifies the messages that it receives from the trusted application and generates a response message to the trusted application. The trusted application processes the message and verifies that it was created by the server, thereby authenticating the server.
Note: Before running the sample, make sure the server is running. To run the server, locate the SDK installation on your disk and double-click \DALsdk\Samples\DALSamplesServer\DALSamplesServer.sln Then run the project.
The Sample Flow
- The trusted application generates an S1 message that the host application transfers to the server. The S1 message contains:
- Intel EPID group ID of this platform
- Public part of the Diffie-Hellman key, ga, generated for the current SIGMA session.
- OCSP request generated for this session
- The server processes and verifies the S1 message.
- The server derives SMK, SK and MK.
- SMK: Session Message Key - Derived from gab to verify SIGMA messages and used to derive SK and MK.
- MK: Session Integrity Key - 128bit key derived from SMK and used for creating ICVs (Integrity Check Values) for each message passed between the verifier and the prover.
- SK: Session Confidentiality Key - 128bit key derived from SMK and used for encrypting messages between the verifier and prover.
- The server generates an S2 message which is transferred to the trusted application by the host application. The S2 message contains:
- Public part of the Diffie-Hellman key, gb
- Sig(ga || gb) - The signature of (ga || gb).
- SIG-RL (revocation list) corresponding to the group ID of the prover - optional.
- BaseName that will be part of the Intel EPID signature in S3 or 0x00 for random based signatures.
- OCSP request that the server received from the trusted application in the S1 message.
- Verifier certificate
- OCSP response
- The trusted application processes and verifies the S2 message.
- The trusted application generates an S3 message which is then transferred to the server by the host application. The S3 message contains:
- Task information that identifies the initiator of this SIGMA session inside the firmware, including the specific trusted application that created this session according to the UUID
- Prover's Intel EPID certificate
- Prover's public part of the Diffie-Hellman key, ga, identical to the one sent in S1.
- HMAC computed using the session MAC key on several fields in the message, as required by the protocol.
- Non-revoked proofs created by the prover, based on the Signature Revocation List from S2.
- The verifier computes the MAC of SIG-RL, BaseName, OCSPReq, OCSP response(s) and the verifier certificate using SMK.
- The prover derives SMK, SK and MK as described above.
- The server processes and verifies the S3 message.
Now both parties have one shared secret and can use any symmetrical encryption algorithm.