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 § |