Difference between revisions of "Security"

Jump to: navigation, search
m (Useful literarure)
m (Fixed broken pdf links)
Line 240: Line 240:
# '''Patent description''' with nice graphics [http://www.faqs.org/patents/app/20090320110]
# '''Patent description''' with nice graphics [http://www.faqs.org/patents/app/20090320110]
# '''M-Shield description''' [[File:NRCTR2007015.pdf]] [http://droid-developers.org/files/m-shield/NRCTR2007015.pdf]
# '''M-Shield description''' [[File:NRCTR2007015.pdf]]
# '''MCM Specification''' [[File:87852F33-1D09-3519-AD0C0F141CC6B10D.pdf]] [http://droid-developers.org/files/m-shield/87852F33-1D09-3519-AD0C0F141CC6B10D.pdf]
# '''MCM Specification''' [[File:87852F33-1D09-3519-AD0C0F141CC6B10D.pdf]]
# '''Trusted Mobile Reference Architecture''' [[File:644597BE-1D09-3519-AD5ADDAFA0B539D2.pdf]] [http://droid-developers.org/files/m-shield/644597BE-1D09-3519-AD5ADDAFA0B539D2.pdf]
# '''Trusted Mobile Reference Architecture''' [[File:644597BE-1D09-3519-AD5ADDAFA0B539D2.pdf]]
# '''MTM Use cases''' [[File:6443B207-1D09-3519-AD3180491A6DF1F5.pdf]] [http://droid-developers.org/files/m-shield/6443B207-1D09-3519-AD3180491A6DF1F5.pdf]
# '''MTM Use cases''' [[File:6443B207-1D09-3519-AD3180491A6DF1F5.pdf]]
=== Other Staff (needed to be cleared) ===
=== Other Staff (needed to be cleared) ===

Revision as of 19:06, 27 December 2010


Security of Motorola Droid-family phones based on two important technologies:

  • eFuse cells for one-time blowing to increment counter for security purposes
  • M-Shield protection, solution from Texas Instruments special for cellular networks (similar as SecureShield from Quallcomm)
  • L3 firewall protection for managing mandatory access for devices in OMAP SoC


L3 firewall


This is an extended implementation of MTM (Mobile Trusted Module) of Trusted Computing Group, based on reference design of MTM, and embedded into OMAP chip. Also it support TrustZone ARM technology. It's located on it's own ROM/RAM and in M-Shield only software emulation - see TrustZone specification. Both, Secure and Insecure world are running on one core. From insecure world it's called by the SMC ARM instruction:

  1.                  ; =============== S U B R O U T I N E =======================================
  2. 4001537C
  3. 4001537C                 ; running in ARM mode
  4. 4001537C
  5. 4001537C                 ; __int32 __cdecl security_monitor_call(__int32 ssid, __int32 proc_id, __int32 flag, __int32 params_addr)
  6. 4001537C                 security_monitor_call                                                 ; CODE XREF: security_monitor_handler+8
  7. 4001537C 000 F0 5F 2D E9           STMFD SP!, {R4-R12,LR}                                      ; Store Block to Memory
  8. 40015380 028 FF 60 A0 E3           MOV   R6, #0xFF                                             ; Rd = Op2
  9. 40015384 028 00 C0 A0 E3           MOV   R12, #0                                               ; Rd = Op2
  10. 40015388 028 95 0F 07 EE           MCR   p15, 0, R0,c7,c5, 4                                   ; prefetch flush
  11. 4001538C 028 9A 0F 07 EE           MCR   p15, 0, R0,c7,c10, 4                                  ; data synchronisation barrier
  12. 40015390 028 71 00 60 E1           SMC   1                                                     ; Secure Monitor Call
  13. 40015394 028 02 00 00 EA           B     service_end                                           ; Branch
  14. 40015394 028
  15. 40015398                 ; ---------------------------------------------------------------------------
  16. 40015398 028 00 F0 20 E3           NOP                                                         ; No Operation
  17. 4001539C 028 FE C0 A0 E3           MOV   R12, #SMC_IRQ_END                                     ; Rd = Op2
  18. 400153A0 028 71 00 60 E1           SMC   1                                                     ; Secure Monitor Call
  19. 400153A0 028
  20. 400153A4
  21. 400153A4                 service_end                                                           ; CODE XREF: security_monitor_call+18
  22. 400153A4 028 F0 5F BD E8           LDMFD SP!, {R4-R12,LR}                                      ; Load Block from Memory
  23. 400153A8 000 1E FF 2F E1           BX    LR                                                    ; Branch to/from Thumb mode
  24. 400153A8 000
  25. 400153A8                 ; End of function security_monitor_call

OMAP3430 have

Normal World Secure World
32Kb on-chip ROM 64Kb on-chip Secure ROM
32Kb on-chip SRAM 32Kb on-chip Secure SRAM

Here is full TrustZone description - File:Prd29-genc-009492c trustzone security whitepaper.pdf

In our target device, the native handset boot starts exe- cuting from an on-chip ROM, which in turns loads a signed bootloader and executes it on successful verification. The M-Shield architecture additionally includes on-chip RAM to be used by so-called protected applications. These can either persistently be present on an on-chip ROM, or be uploaded to on-chip RAM as signed binaries. The system implements a firewall/monitor entry point for executing these applica- tions, and this firewall takes care of disabling or clearing all security-critical processor features (interrupts, DMA, VM) for the duration of the TrEE invocation. In this manner the system provides hardware-enforced isolation for the pro- tected applications. The on-chip protected applications have access to a limited amount of persistent secret data (like a device-specific symmetric key) and to cryptographic accelerator primitives.


Sheme.gif 2007 06-nokia-figure-2.gif Arch 1.jpg

  1. ROM to store the program code or a mechanism by which the integrity of code uploaded to the secure environment can be validated (code signing).
  2. a shielded location (secure RAM) for the loaded state, as well as for run-time data.
  3. an isolated execution environment (TrEE) for the program code with access to the shielded data location.
  4. a device-specific, persistent secret to seed the RTS. The confidentiality (access control) of the secret can e.g. be bound to the secure environment itself.
  5. a simple (I/O) library for use in the isolated environment, including cryptographic primitives and random number generation necessary for a MTM.1


Abbreviation Meaning
AKI Attestation Identity Key
EK Endorcement Key
DAA Direct Anonymous Attestation
DRTM Dynamic Root of Trust Management
MTM Mobile Trusted Module
RIM Reference Integrity Metric
RTE Root of Trust for Enforcement
RTR Root of Trust for Reporting
RTS Root of Trust for Storage
RTV Root of Trust for Verification
RVAI Root Verification Authority Information
SRK Storage Root Key, is used to protect local data (keys e.g)

Listing 1: Structure for symmetric SRK

  1. // 128 bits key length                        
  2. #define SRK KEYLENGTH 16  
  4. typedef struct tdTPM KEY SRK {
  5.   TPM STRUCT VER ver;
  6.   TPM KEY USAGE keyUsage;
  7.   TPM KEY FLAGS keyFlags;
  8.   TPM AUTH DATA USAGE authDataUsage;
  9.   TPM KEY PARMS algorithmParms;
  10.   TPM SECRET usageAuth;
  11.   UINT32 PCRInfoSize;
  12.   TPM PCR INFO pcrInfo;
  13.   BYTE symKey[SRK KEYLENGTH];
  14. } TPM KEY SRK;
  15. // Size of TPM KEY SRK in bytes: 123

Listing 2: Structure for loaded asymmetric key

  1. typedef struct tdTPM KEY LOADED {
  2. TPM STRUCT VER ver;
  3. TPM KEY USAGE keyUsage;
  4. TPM KEY FLAGS keyFlags;
  5. TPM AUTH DATA USAGE authDataUsage;
  6. TPM KEY PARMS algorithmParms;
  7. TPM KEY PARMS algorithmParms;
  8. UINT32 PCRInfoSize;
  9. UINT32 PCRInfoSize;
  10. TPM PCR INFO pcrInfo;
  11. TPM STORE ASYMKEY keyData;
  13. // Size of TPM KEY LOADED in bytes: 551


  1. typedef struct tdTPM PCR ATTRIBUTES {
  2.   BOOL pcrReset;
  5. // Size of TPM PCR ATTRIBUTES in bytes: 1
  6. typedef struct tdTPM PERMANENT FLAGS {
  8.   BOOL disable;
  9.   BOOL FIPS;
  11.   BOOL readSRKPub;
  14. // Size of TPM PERMANENT FLAGS in bytes: 5
  15. typedef struct tdTPM STCLEAR FLAGS {
  16.   TPM STRUCTURE TAG tag;
  17.   BOOL deactivated;
  20. // Size of TPM STCLEAR FLAGS in bytes: 3
  21. typedef struct tdTPM STANY FLAGS {
  22.   TPM STRUCTURE TAG tag;
  23.   BOOL postInitialise;
  26. // Size of TPM STANY FLAGS in bytes: 3
  27. #define TPM SESSIONS 2
  28. typedef struct tdTPM STANY DATA {
  29.   TPM STRUCTURE TAG tag;
  33. // Size of TPM STANY DATA in bytes: 98
  34. #define TPM NUM COUNTER 1
  35. #define TPM NUM PCR 16
  37. typedef struct tdTPM PERMANENT DATA {
  38.   TPM STRUCTURE TAG tag;
  39.   BYTE revMajor;
  40.   BYTE revMinor;
  41.   TPM NONCE tpmProof;
  42.   TPM KEY srk;
  43.   TPM COUNTER VALUE monotonicCounter[TPM NUM COUNTER];
  47. // Size of TPM PERMANENT DATA in bytes: 173
  48. typedef struct tdTPM STCLEAR DATA {
  49.   TPM STRUCTURE TAG tag;
  50.   TPM COUNT ID countID;
  53. // Size of TPM STCLEAR DATA in bytes: 326

Software Emulators:

  1. MTM Emulator - http://mtm.nrsec.com/
  2. TroUserS http://trousers.sourceforge.net/ (http://sourceforge.net/projects/trousers/)
  3. http://tpm-emulator.berlios.de/

Useful literarure

  1. Patent description with nice graphics [2]
  1. M-Shield description File:NRCTR2007015.pdf
  1. MCM Specification File:87852F33-1D09-3519-AD0C0F141CC6B10D.pdf
  1. Trusted Mobile Reference Architecture File:644597BE-1D09-3519-AD5ADDAFA0B539D2.pdf
  1. MTM Use cases File:6443B207-1D09-3519-AD3180491A6DF1F5.pdf

Other Staff (needed to be cleared)

Work history Motorola June 2005 to the present Senior Software Engineer

tags: c • stracore • tms320c55x+ How would you describe your time at Motorola?

   1. Implementation of Alternate Linear Output Equalizer (ALOE) for GSM handsets.
   Tools: Code Composer Studio (CCS), Freescale code warrior simulation tool.
   Language: TMS320C55x+ Algebraic Assembly, STARCORE ASSEMBLY
   Description: The ALOE algorithm is aimed at improving co-channel performance of the handset over the conventional GSM equalizers. The new algorithm gives 13 dB improvements over the conventional MLSE method.
   The implementation of this algorithm involved the coding in TMS320C55x+ Algebraic Assembly using CCS tool. And implementation is targeted to have lesser MIPS and better precision results. The algorithm testing is done with legacy starcore reference code.
   2. Implementation of G728 speech codec with FIXED POINT, 32/16 bit data paths.
   Tools: Freescale code warrior simulation tool.
   Description: The G728 speech codec adhering to the ITUT standards is implemented using fixed point 16 bit and 32 bit data paths. The 16 bit fixed point data path is bit complaint with ITUT standard provided testvectors.The work involved is implementation, integration and Testing of entire G728 codec of 32 bit and 16 bit precisions and analysis with fixed point arithmetic using C language. And then porting the C code to the STARCORE architecture and also porting to starcore assembly to meet the MIPS criterion. The code is implemented in C and then star core assembly coded to meet MIPS criterion.
   3. Development and Testing of Sync Detection, AFC, and sensitivity improvement algorithms.
   Tools: Matlab Freescale code warrior simulation tool.
   Description: The IDEN (similar to GSM) system has RF modem part which has Transmitter and Receiver. The Receiver is to demodulate the received Quad QAM data into in-Phase and Quadrature symbols, by applying sub channel demodulation, time synchronization, automatic frequency control, pilot interpolation and data decoding algorithms.
   The work involved implementation of AFC using the 1st order loop and synchronization using WLS algorithm and sensitivity improvement algorithm using 4-F Doppler mutipath fading modeling .The implementation of all these algorithms are on C, and STARCORE ASSEMBLY using the freescale code warrior tools....

RNG, DES/3DESx2, SHA1/MD5x2, AESx2, Fast PKA (Safenet EIP-29), e-fuse

On-Chip Memory: 96 Kbytes ROM, 64 Kbytes SRAM

M-Shield Hardware Security Technology

Integrated into TI's OMAP and OMAP-Vox platforms, M-Shield hardware security technology is a complete infrastructure for mobile platform robustness that includes:

   * Hardware cryptographic accelerators and randon number generator
   * Public key infrastructure with secure on-chip keys (e-fuse)
   * Secure booting and flashing
   * Secure access/restriction to all chip peripherals and memories
   * Secure DMA transfers
   * Hardware-based countermeasures against software attacks and cloning
   * Secure protection of debug, trace, and test capabilities
   * Hardware-reinforced secure execution and storage environment (Secure Environment) embedding:
         o A Secure State Machine
         o Secure RAM for sensitive authorized application execution and secure data storage
         o Secure ROM with 100+ accessible by authorized applications (Protected Applications) 
         o Secure storage mechanism

M-Shield hardware security technology is operating system-independent and not sensitive to software attacks. And once it is available, ARM® TrustZone™ hardware extensions will be incorporated and strengthened. M-Shield Software Security Technology

M-shield software security technology is the key software-based security element of OMAP Platforms and OMAP-Vox devices, built on top of and strengthened by M-Shield Hardware technology. This software security encompasses:

   * Secure signing and flashing tools
   * IMEI and SIMlock protection software on OMAP-Vox devices
   * Toolkits for development and signature of protected applications running in a secure environment
   * Security Middleware Component with associated Protected Applications and SDKs
   * Security packs to strengthen HLOS security

Additionally, the M-shield Security Middleware Component (SMC) provides sets of standard APIs that solve the problems of de-fragmentation and porting complexity:

   * Software reuse across platform generations as APIs on current platforms can continue to be utilized
   * SMC APIs are compatible with ARM® TrustZone™ software APIs
         o Applications can call specific secure services ported on SMC using ARM TrustZone API
         o Applications can use secure storage and standard PKCS#11 APIs for cryptography
         o Native secure services can use standard PKCS#11 APIs
         o Interpreted secure services can use GlobalPlatform GPD/STIP mobile profile standard APIs
   * Applications developed on TI's M-shield mobile security technology today will run binary compatible on devices incorporating an ARM core with TrustZone hardware extensions
   * Services developed today using ARM TrustZone software API will run on TI devices with M-Shield mobile security technology

Some info about eFuse in OMAP - http://elinux.org/OMAP_Power_Management/SmartReflex

All Secure ROM soultion based on Synopsys products http://www.synopsys.com/Tools/SLD/CapsuleModule/vp_ti_ss.pdf