Skip to content

Appendix C: Secure Device Onboard 1.1 Crypto Upgrade

In October of 2017, the Security Architecture Forum (Intel Internal forum) (SAFE) Crypto Guidelines were upgraded, based on the potential threat of quantum cryptography. This table indicates crypto levels to apply. Secure Device Onboard 1.0 and Secure Device Onboard 1.1 protocol spec use the left column, and the new crypto strength is given in the “Future Crypto” column; it will be assigned a Secure Device Onboard release in the future.

The length of a release is generally outside the scope of this document; however, implementers of Secure Device Onboard Service and Owner components must take care to ensure that Devices using Secure Device Onboard 1.1 crypto must be supported by all Secure Device Onboard components for the life of the Secure Device Onboard 1.1 release.

.
Category Secure Device Onboard 1.0 & Secure Device Onboard 1.1 Future Crypto (Enhanced Strength for Quantum Crypto) Comments
Device HMAC HMAC-SHA-256 with HMAC secret of 128 bits HMAC-SHA-384 with HMAC secret of 512 bits Bay Trail grandfathered for SHA-256 See §
Hash of Owner Key SHA-256 SHA-384 (inside Device DI protocol) It is also permissible to store the entire Owner key. See §
Ownership Voucher (Owner attestation) RSA2048 Use RSA2048RESTR as public key type. RSA3072, except Bay Trail Use RSA_UR as public key type. Bay Trail grandfathered for RSA2048RESTR option. See §
Ownership Voucher (Owner attestation) ECDSA NIST P-256 ECDSA NIST P-384 P-384 not supported by some crypto chips; it may be possible to grandfather them in. See §
Ownership Voucher SHA-256 SHA-384 Bay Trail grandfathered for SHA-256. See §
Device attestation EPID1.0, 1.1, 2.0 Per platform No change Intel® EPID is under evaluation by SAFE; Later versions of Intel® EPID are being developed by labs. See §
Ownership Voucher SHA-256 SHA-384 Bay Trail grandfathered for SHA-256. See §
Device attestation ECDSA ECDSA NIST P-256 (with SHA-256 hash) & ECDSA NIST P-384 (with SHA-384 hash) ECDSA NIST P-384 (with SHA-384 hash) This is the device attestation key built into the device. See §
Key Exchange, DH Id14 (2048-bit modulus) a, b are 256 bits each Id15 (3072 bit modulus) a, b are 768 bits each New modulus available from same RFC as old, see refs. Increased entropy needed for SVK, SEK. See §
Key Exchange, Asymmetric RSA2048RESTR RSA-OAEP-MGF-SHA256 Device, Owner Random of 256 bits RSA_UR, 3072 bits RSA-OAEP-MGF-SHA256 Device, Owner Random of 768 bits *SHA256* may be used here as mask generation function for RSA-OAEP. Larger D&O Randoms required for SVK, SEK. See §
Key Exchange, ECDH ECC NIST P-256 or NIST P-384, keys used once only Device, Owner random of 128 bits ECC NIST P-384, keys used once only Device, Owner random of 384 bits Larger D&O Randoms required for SVK, SEK. See §
Key Exchange, ECDH, LEGACY ECC NIST P-256, keys used once only Device, Owner random of 128 bits ECC NIST P-256, keys used once only Device, Owner random of 512 bits Note that this mode can only be used for legacy hardware, with approval from PSE. See §
Key Derivation Function (*‎2.5.5.4*) SHA-256 based SEK, SVK entropy is 128 bits (SVK 256 bits, but with lower entropy) SHA-384 based SEK is 256 bits SVK is 512 bits Note changes to Device and Owner Randoms in key exchange algorithms to support this change. See §
SEK (Session Encryption Key) 128 bits 256 bits Matches TO2 Session Encryption modes. See Table in § ; also see §
SVK (Session Verification Key) 256 bits, with 128 bits entropy 512 bits Based on 512 bit state of SHA-384. See Table in § ; also see §
TO2 Session HMAC HMAC-SHA-256 HMAC-SHA-384 HMAC key is 512 bits. See Table in § ; also see §
TO2 Session Encryption, counter mode AES-128/CTR IV 12 bytes, Counter is 4 bytes. AES-256/CTR IV is 12 bytes, Counter is 4 bytes Note session limits on TO2 protocol (See §).
TO2 Session Encryption, CBC mode AES-128/CBC IV is 16 bytes AES-256/CBC IV is 16 bytes Note session limits on TO2 protocol (See §).
TO2 Protocol Roundtrip Limit 1M (1e6) rounds 1M (1e6) rounds Required limit for AES/CTR mode. Increased limit is to permit small files to be transmitted in ServiceInfo, esp for MCUs. See §