for Constrained IoT Devices Y. Jia, B. Liu, W. Jiang, B. Wu, C. Wang - PowerPoint PPT Presentation

Enhancing Remote Healthiness Attestation for Constrained IoT Devices Y. Jia, B. Liu, W. Jiang, B. Wu, C. Wang IEEE ICNP 2020 Madrid, Spain, October 13-16, 2020 HUAWEI TECHNOLOGIES CO., LTD.

IoT Devices are keeping losing control… IoT devices remain vulnerable … Hackers are lunching DDoS with IoT devices… Mirai attacks… Peak 1.7 Tbps IoT Devices

Reasons behind the constantly vulnerabilities Shaping Market Constrained Resources… Hacking Hacker Unaffordable Security mechanisms IoT Hacked!

Given that IoT devices are inevitably vulnerable , the question goes to: How could we timely identify hacked IoT devices? Remote Attestation

Universal Remote Attestation Trusted STEP 1 Module BOOTUP Trusted Boot Power off Started Trusted boot mechanism Credentials Endorsed by Trusted Module Pull the Credentials STEP 2 With the Trusted Module endorsement Remote attestation IP Network Channel • Built by the manufacturer Running • Trusted by the Authorized Verifier • All in an out-of-band manner

A dedicated Trust Module is way too heavy/expensive… Could it be evolved for the constrained IoTs? DICE(Device Identifier Composition Engine)

The DICE(Device Identifier Composition Engine) Proposal • Initially proposed by Microsoft • Standardized by standardize 2 specifications of the DICE-based remote attestation • ① ② symmetric crypto DICE asymmetric crypto DICE Standardized by 2020 Standardized by 2018

DICE with the Asymmetric crypto The higher the layer is, the more functions and attacking surface there will be. Bootup layer by layer DICE Engine Layer 0 Layer 1 Layer 2 Layer n BOOTUP [SK * ] [SK 0 ] [SK 1 ] [SK 2 ] [SK n ] … … Certificate 0 Certificate 1 Certificate 2 Certificate n PK 0 PK 1 PK 2 PK n … … Hash(L 0 ) Hash(L 1 ) Hash(L 2 ) Hash(L n ) Signed by SK * Signed by SK 0 Signed by SK 1 Signed by SK n-1 Device Side DTLS Handshake [Authentication] Verifier Side Certificate 0 Certificate 1 Certificate 2 Certificate n Certificate Certificate PK 0 PK 1 PK 2 PK n IDevID ROOT Hash(L 0 ) Hash(L 1 ) Hash(L 2 ) Hash(L n ) PK CA PK * … … Signed by SK * Signed by SK 0 Signed by SK 1 Signed by SK n-1 Signed by SK CA Signed by SK CA Database H0 | H1 | H2 | H3 | … | Hn Prerequisites Design Key: DICE Engine is developed and installed by the manufacturer; DICE Engine stores a SK(private key)/PK(public key) pair for the endorsement; • • The source code of the DICE Engine too tiny to be hacked ; DICE Engine will be shut down immediately once layer 0 booted up; • • DICE Engine is unconditionally trusted by the Verifier; The short running interval guarantees that the SK(private key) is only readable • • for the DICE Engine itself, and thus inaccessible by any other layers; The validation is based on the certificate-chain

DICE with the Symmetric crypto The design principles are all the same as the Asymmetric crypto based DICE BOOTUP Layer n-1 Layer n DICE Layer 0 Layer 1 Layer 2 … … Secret 0 Secret 1 Secret n-1 Secret n UDS* Secret 2 Secret 1 =HMAC(Secret 0 , H(L 1 )) Secret 3 =HMAC(Secret 2 , H(L 3 )) Secret 2 =HMAC(Secret 1 , H(L 2 )) Secret 0 =HMAC(UDS, H(L 0 )) Secret n =HMAC(Secret n-1 , H(L n )) Firmware Version ID PSK=KDF(Secret n ) Device Side DTLS Handshake [Authentication] Verifier Side Consistency Database Validation Firmware Version H0 | H1 | H2 | H3 | … | Hn Database Algorithm PSK* PSK ID UDS The Algorithm is the same as the device boot up Key Points UDS : Unique Device Secret --- A Symmetric key • The UDS is shared with and trusted by verifiers • The validation is based on the Hash-chain

NEVERTHELESS Replay Attacks are behind DICE…

Threat: steal the credentials and then replay … NOTE ： DICE DO NOT offer the capability of the secure storage Credentials e.g. TEE H323CD87LKUE7BGH… Impractical Hardware Level Protection Unconstrained IoT Devices （ Powered ） Steal the credential By access devices physical or remotely Constrained IoT Devices （ Battery ） Possible The credential is static … Software Level Protection Replay… Once stolen Credentials the replay attacks survives … 7LK5UE27B5GHFEG3Y…

DICE+: Design Consideration Main Consideration Secure Direction 1 ： Replay attack resilience Light-weight Direction 2 ： adaptive for the constrained IoT Devices Accuracy Direction 3 ： Fine-grained firmware attestation DICE+ UPGRADE… DICE

Identifying the replay... Convert the Credential from STATIC to DYNAMIC ! Static Dynamic SEED Nonce Counter Timestamp

DICE+: Design Details Evolution from the Symmetric crypto DICE BOOT Layer 1 Layer n … … DICE Layer 0 KEY 1 Secret 1 Secret n KEY n KEY 0 Secret 0 UDS CNT KEY 1 =H(KEY 0 ) KEY n =H(KEY n-1 ) KEY 0 =HMAC(UDS, CNT) CNT+1 Every time bootup Secret n =HMAC(KEY n-1 *, H(L n )) Secret 0 =HMAC(LUDS, H(L 0 )) Secret 1 =HMAC(KEY 0 , H(L 1 )) … … ID Firmware Version D = (Secret 0 , Secret 1 , Secret 2 , … , Secret n ) PSK=H(D) Device Side DTLS Handshake [Authentication] Verifier Side Consistency Database Validation Firmware Version H0 | H1 | H2 | H3 | … | Hn D D* Database Algorithm ID PSK* PSK UDS MAIN CHANGES The Algorithm is the same as the device boot up Seed involved: A counter is introduced in the DICE engine • OTHER OPTIMIZATIONS Symmetric crypto: remain the extreme light-weight overhead • KEY n CNT New algorithm : A parameter is introduced in every layer boot up •

Conclusion: What DICE+ Improve? DICE+ CHALLENGE 2 ： Computationally costly UPDATE 2 ： Extreme constrained IoT Asymmetric crypto computation consumes energy • 1. energy consumptions reduce 1000x 2. chip size for security area can reduce ~60% Certificate-chain transfer consumes energy • DICE [Asymmetric] UPDATE 1 ： Resilient for Replay CHALLENGE 1 ： Replay Attack Verifiers can adjust the period of the validity of the seed • The static credentials are easy to replay… • Verifiers is able to identify the hacked devices that have • been imitated by the replay attacks . DICE [Symmetric] UPDATE 3 ： Hacked Layer Identification CHALLENGE 3 ： Coarse-grained attestation Verifiers are unable to identify the specific hacked layer Verifiers are able to identify in which layer the IoT devices • • have been hacked.

THANKS! IEEE ICNP 2020 Madrid, Spain, October 13-16, 2020 HUAWEI TECHNOLOGIES CO., LTD.