Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Secure storage updates - SFO17-309

410 views

Published on

Session ID: SFO17-309
Session Name: Secure storage updates - SFO17-309
Speaker: Jens Wiklander - Jerome Forissier

Track: Security


★ Session Summary ★
The last release of OP-TEE includes big updates to secure storage. Integrity protection is improved and the entire secure storage space is saved as one snapshot on each update.
---------------------------------------------------
★ Resources ★
Event Page: http://connect.linaro.org/resource/sfo17/sfo17-309/
Presentation:
Video:
---------------------------------------------------

★ Event Details ★
Linaro Connect San Francisco 2017 (SFO17)
25-29 September 2017
Hyatt Regency San Francisco Airport

---------------------------------------------------
Keyword:
http://www.linaro.org
http://connect.linaro.org
---------------------------------------------------
Follow us on Social Media
https://www.facebook.com/LinaroOrg
https://twitter.com/linaroorg
https://www.youtube.com/user/linaroorg?sub_confirmation=1
https://www.linkedin.com/company/1026961

Published in: Technology
  • Be the first to comment

Secure storage updates - SFO17-309

  1. 1. Secure storage in OP-TEE Jens Wiklander
  2. 2. ENGINEERS AND DEVICES WORKING TOGETHER Agenda ● What is secure storage? ● Timeline - secure storage improvements ● Encryption keys ● Secure Object ○ Hash tree ○ Hash tree header ○ Data block encryption ○ Atomic updates ● Object list ● Anti-rollback with RPMB ● What’s next?
  3. 3. ENGINEERS AND DEVICES WORKING TOGETHER What is Secure Storage? ● Persistent data store for crypto keys or other application-specific data ● Accessible to Trusted Applications only ○ Each TA has its own storage (TA isolation) ● Isolated from the non-secure world ○ Secure Storage data can’t be read, modified or deleted by user applications or the OS kernel ● OP-TEE implements the GlobalPlatform™ TEE Internal Core API v1.1 ○ Chapter 5: Trusted Storage API for Data and Keys ; Persistent Object [Enumeration] Functions and Data Stream Access Functions TEE_OpenPersistentObject() TEE_AllocatePersistentObjectEnumerator() TEE_CreatePersistentObject() TEE_FreePersistentObjectEnumerator() TEE_CloseAndDeletePersistentObject1() TEE_ResetPersistentObjectEnumerator() TEE_RenamePersistentObject() TEE_StartPersistentObjectEnumerator() TEE_ReadObjectData() TEE_GetNextPersistentObject() TEE_WriteObjectData() TEE_TruncateObjectData() TEE_SeekObjectData()
  4. 4. ENGINEERS AND DEVICES WORKING TOGETHER Timeline - secure storage improvements 1.0 1.1 2.0 2.1 2.2 2.3 2.4 2.5 RPMB Better TA isolation Improved integrity with added hash tree Xtest 20000 (corruption tests) Encryption atomicity Multiple storage support Single file per object, remove block cache Anti-rollback protection using RPMB
  5. 5. ENGINEERS AND DEVICES WORKING TOGETHER Encryption keys ● Authenticated block encryption (AES-GCM), one File Encryption Key (FEK) per file ● FEK is AES-encrypted using a 256-bit Trusted application storage Key (TSK) then stored in the metadata of the file ● TSK is derived from Secure Storage Key (SSK) and the Trusted Application UUID using HMAC-SHA256 ● SSK is derived from a Hardware Unique Key (HUK) and a constant string using HMAC-SHA256
  6. 6. ENGINEERS AND DEVICES WORKING TOGETHER Hash tree ● A complete binary tree ● Each node protects one data block (tag and IV from AES-GCM operation) ● Hash calculated as: SHA-256(tag || IV || flags || hashchild0 || hashchild1 ) ● Nodes start counting from 1 and data blocks from 0 ○ this means that node 1 holds tag and IV for data block 0 Node 1 Node 3Node 2 Node 4 Node 5 Node 6
  7. 7. ENGINEERS AND DEVICES WORKING TOGETHER Hash tree header ● File encryption key, FEKC ● Counter ○ In case of no rollback protection, this is used to select the latest version ● Metadata ○ Number of nodes ○ Payload length
  8. 8. ENGINEERS AND DEVICES WORKING TOGETHER Hash tree header continued The hash tree header is constructed with the following steps 1. A new Initialization Vector, IV, is initialized from RNG 2. If FEKC is not initialized yet, FEKP is initialized from RNG and Encrypted FEK, FEKC = AES-ECBENC (SSK, FEKP ) 3. Counter is increased by one or if not yet initialized set to 1 4. AAD = Node1.hash || Counter || FEKC || IV 5. (Tag, MetadataC ) = AES-GCMENC (FEKP , IV, Metadata, AAD) 6. The header is finally assembled as: IV || Tag || FEKC || MetadataC || Counter
  9. 9. ENGINEERS AND DEVICES WORKING TOGETHER Data block encryption An encrypted data block, C, is constructed with the following steps 1. A new Initialization Vector, IV, is initialized from RNG 2. P, is the unencrypted block of data 3. FEK = AES-ECBDEC (SSK, FEKC ) 4. Additional Authenticated Data, AAD = FEKC || IV 5. Tag and C is produced with: (Tag, C) = AES-GCM(FEKP , IV, P, AAD) Tag and IV are saved in the node protecting the encrypted data block.
  10. 10. ENGINEERS AND DEVICES WORKING TOGETHER Atomic updates ● All parts of a secure storage object exists in two backup versions, 0 and 1 ● The backup version in use is called the active version and the other version the inactive version ● The different parts are ○ Hash tree header ○ Hash tree node ○ Encrypted Data block ● All updates are done in the inactive versions until finally the hash of the inactive node1 has been written into the object list database
  11. 11. ENGINEERS AND DEVICES WORKING TOGETHER Object list database Secure objects created by Trusted Applications, TAs, are indexed in a special secure object UUID of TA Uniquely identifies a secure object Object Identifier Hash Hash of node1 in secure object file_number Global unique file number
  12. 12. ENGINEERS AND DEVICES WORKING TOGETHER Object list database continued ● The object list database is stored under the name “dirf.db” in normal world ● If RPMB is available the hash of node1 is stored in RPMB and has full anti-rollback protection ● If RPMB is unavailable only a consistent state of all objects can be provided, that is, rollback can’t be applied on a single object
  13. 13. ENGINEERS AND DEVICES WORKING TOGETHER What’s next? ● RPMB: don’t program key unless some debug/testing CFG_ is set ● Improve derivation of SSK from HUK ○ Should be done by the hardware crypto module. HUK should never be read by software. ○ Unfortunately, we have no such driver upstream :( ● Reduce heap usage ○ Large objects uses much memory for nodes ● Storing Trusted Applications in secure storage
  14. 14. Thank You #SFO17 SFO17 keynotes and videos on: connect.linaro.org For further information: www.linaro.org

×