enhancing remote healthiness attestation for constrained ...update 2：extreme constrained iot 1....
TRANSCRIPT
HUAWEI TECHNOLOGIES CO., LTD.
Enhancing Remote Healthiness Attestation
for Constrained IoT DevicesY. Jia, B. Liu, W. Jiang, B. Wu, C. Wang
IEEE ICNP 2020
Madrid, Spain, October 13-16, 2020
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
Constrained Resources…Market
Shaping
Hacking
Hacker UnaffordableSecurity 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
StartedPower off
BOOTUP
Trusted boot mechanism
Credentials
Endorsed by Trusted Module
STEP 1
STEP 2
Trusted Module
Running
IP Network Channel
• Built by the manufacturer• Trusted by the Authorized Verifier• All in an out-of-band manner
Pull the CredentialsWith the Trusted Module endorsement
Trusted Boot
Remote attestation
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
Device Side
Verifier Side
DICE Engine[SK*]
Layer 0[SK0]
Layer 1[SK1]
Layer 2[SK2]
Layer n[SKn]
… …
Signed by SK*
Certificate 0PK0
Signed by SK0
Certificate 1PK1
Signed by SK1
Certificate 2PK2
Signed by SKn-1
Certificate nPKn
… …Hash(L0) Hash(L1) Hash(L2) Hash(Ln)
Signed by SK*
Certificate 0PK0
Signed by SK0
Certificate 1PK1
Signed by SK1
Certificate 2PK2
Signed by SKn-1
Certificate nPKn
… …Hash(L0) Hash(L1) Hash(L2) Hash(Ln)
Signed by SKCA
Certificate IDevIDPK*
DTLS Handshake [Authentication]
Database H0 | H1 | H2 | H3 | … | Hn
BOOTUP
Signed by SKCA
Certificate ROOTPKCA
Prerequisites
• DICE Engine is developed and installed by the manufacturer;
• The source code of the DICE Engine too tiny to be hacked;
• DICE Engine is unconditionally trusted by the Verifier;
The higher the layer is, the more functions and attacking surface there will be.Bootup layer by layer
Design Key:
• DICE Engine stores a SK(private key)/PK(public key) pair for the endorsement;
• DICE Engine will be shut down immediately once layer 0 booted up;
• 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
ID PSK*
DICE
UDS*… …
Secret0=HMAC(UDS, H(L0))
Layer 0
Secret 0
Secret1=HMAC(Secret0, H(L1))
PSK=KDF(Secretn)
Layer 1
Secret 1
Layer 2
Secret 2
Layer n
Secret n
Layer n-1
Secret n-1
Secret2=HMAC(Secret1, H(L2))
Secret3=HMAC(Secret2, H(L3))
Secretn=HMAC(Secretn-1, H(Ln))
Database
H0 | H1 | H2 | H3 | … | Hn
Database
UDS
DTLS Handshake [Authentication]
BOOTUP
ID Firmware Version
PSK
Device Side
Verifier Side
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
The design principles are all the same as the Asymmetric crypto based DICE
The Algorithm is the same as the device boot up
Algorithm
Firmware Version
ConsistencyValidation
NEVERTHELESS
Replay Attacks are behind DICE…
CredentialsH323CD87LKUE7BGH…
Unconstrained IoT Devices（Powered）
Constrained IoT Devices（Battery）
e.g. TEE
Credentials7LK5UE27B5GHFEG3Y…
Steal the credential
By access devices physical or remotely
NOTE：DICE DO NOT offer the capability of the secure storage
Impractical
Possible
Hardware Level Protection
Software Level Protection
Threat: steal the credentials and then replay…
Replay… The credential is static…Once stolenthe replay attacks survives…
DICE+: Design Consideration
Direction 1：Replay attack resilience
Direction 2：adaptive for the constrained IoT Devices
Direction 3：Fine-grained firmware attestation
Secure
Light-weight
Accuracy
DICE
DICE+
UPGRADE…
Main Consideration
Identifying the replay...
Static Dynamic
Convert the Credential from STATIC to DYNAMIC !
SEED
Nonce Counter Timestamp
DICE+: Design Details Evolution from the Symmetric crypto DICE
UDS KEY0
… …
KEY0=HMAC(UDS, CNT)
Secret0=HMAC(LUDS, H(L0))
Secret0
Layer 1
KEY1
KEY1=H(KEY0)
Secret1
Secret1=HMAC(KEY0, H(L1))
KEYn
Secretn=HMAC(KEYn-1*, H(Ln))
Secretn
BOOT
… …
PSK=H(D)
KEYn=H(KEYn-1)
CNT+1 Every time bootup
D = (Secret0, Secret1, Secret2, … , Secretn)
CNT
DTLS Handshake [Authentication]Device Side
Verifier Side
Algorithm PSK*
Database
H0 | H1 | H2 | H3 | … | Hn
Database
UDS
ID Firmware Version
PSK
The Algorithm is the same as the device boot up
DICE Layer 0
D* D
ID
Firmware Version
ConsistencyValidation
• Seed involved: A counter is introduced in the DICE engine
Layer n
KEYn CNT
MAIN CHANGES
• Symmetric crypto: remain the extreme light-weight overhead
• New algorithm: A parameter is introduced in every layer boot up
OTHER OPTIMIZATIONS
CHALLENGE 2：Computationally costly
• Asymmetric crypto computation consumes energy
• Certificate-chain transfer consumes energy
CHALLENGE 1：Replay Attack
• The static credentials are easy to replay…
CHALLENGE 3：Coarse-grained attestation
• Verifiers are unable to identify the specific hacked layer
UPDATE 2：Extreme constrained IoT
1. energy consumptions reduce 1000x
2. chip size for security area can reduce ~60%
UPDATE 3：Hacked Layer Identification
• Verifiers are able to identify in which layer the IoT devices
have been hacked.
UPDATE 1：Resilient for Replay
• Verifiers can adjust the period of the validity of the seed
• Verifiers is able to identify the hacked devices that have
been imitated by the replay attacks.
DICE[Asymmetric]
DICE+
Conclusion: What DICE+ Improve?
DICE[Symmetric]
HUAWEI TECHNOLOGIES CO., LTD.
THANKS!
IEEE ICNP 2020
Madrid, Spain, October 13-16, 2020