"TCG移动领域技术规范1.0版本修订2.03"

需积分: 1 125 浏览量更新于2024-04-14 收藏 2.86MB PDF 举报

The TCG Mobile Abstraction Layer Specification Version 1.0 Revision 2.03, published by Trusted Computing Group in April 2010, is a technical document outlining the standards and guidelines for implementing trusted computing in the mobile domain. This specification serves as a comprehensive guide for developers and manufacturers to ensure the security and integrity of mobile devices and applications. The document emphasizes the importance of protecting sensitive data and ensuring the confidentiality and integrity of information stored on mobile devices. It provides guidelines for the implementation of secure boot, secure storage, secure communications, and secure updates to prevent unauthorized access and tampering. One key aspect of the TCG Mobile Abstraction Layer is the establishment of a standardized interface for secure communication between hardware components and software applications. This helps ensure that sensitive data is encrypted and securely transmitted between different layers of the mobile device, protecting it from malicious attacks and unauthorized access. Additionally, the specification includes guidelines for integrating trusted computing technologies, such as TPMs (Trusted Platform Modules), into mobile devices to enhance security and establish a root of trust. By implementing these technologies, mobile device manufacturers can protect sensitive information, verify the integrity of software components, and detect and respond to potential security threats. Overall, the TCG Mobile Abstraction Layer Specification Version 1.0 Revision 2.03 provides a comprehensive framework for implementing trusted computing in the mobile domain, helping to secure mobile devices and protect user data. It serves as a valuable resource for developers, manufacturers, and security professionals seeking to enhance the security and integrity of mobile applications and devices.

TCG Mobile Abstraction Layer TCG Copyright

Specification Version 1.0 Revision 2.03

29 April 2010 Page 16 of 117

TCG PUBLISHED

4.2 TBB Operation 1

Start of informative comment: 2

Figure 3 illustrates the interfaces to the TBB during measurement and verification. 3

Figure 3. Interfaces 24

In Figure 3, the bottom is the Mobile Trusted Module [5]. On top there is a point of entry called the Trusted 25

Mobile Software Stack (TMSS), which is defined in this specification as the conjunction of the TBB Interface 26

API (Section 6) and Trusted Services API (Section 7), 27

On top of this the „users‟ of the trusted services are shown. These are the OS Applications, Measurement 28

Agents, and Verification Agents. Note, that all of those agents might actually be part of the OS, and there 29

will be interactions between the OS and these agents, which are not depicted above. It is also important to 30

note that in the early stages of the boot process, entities like an RTV and RTM can interact directly with the 31

MTM without going through a TMSS. 32

End of informative comment. 33

TBB

Applications in

Measurement

Agent

Verification

Agent

Trusted Mobile Software Stack

RTV

RTM

MTM (RTS. RTR)

TCG Mobile Abstraction Layer TCG Copyright

Specification Version 1.0 Revision 2.03

29 April 2010 Page 17 of 117

TCG PUBLISHED

4.2.1 Boot-time Operation of the TBB 1

The following steps describe the TBB operations for a secure-boot Engine. 2

1. If the RTE exists, then it MUST run first and MUST build a Secure Execution Environment for the 3

Allocated Roots of Trust. This environment SHOULD contain at least two secure applications – a 4

combined RTM/RTV application (which MAY also act later as the PRMVA), and a combined RTR/RTS 5

application (the MTM). 6

2. The RTM and RTV SHALL start up the MTM, cause it to perform self-tests, load any necessary 7

verification root key, set verified PCRs (if not pre-set), make initial measurements of the HW and the 8

Roots of Trust, and perform verified extends into the MTM. 9

3. The RTM and RTV MAY measure, perform verified extends and initialize other required and optional 10

components as required, following the guidelines laid out within the TCG Mobile Reference 11

Architecture [9]. 12

4. The RTM and RTV SHALL measure a Boot Loader for the Engine‟s Main OS, perform a verified extend 13

of the Boot Loader‟s image into the MTM, and if successful, start the Boot Loader. The RTM and RTV 14

MUST now stop running, but their code MAY later be re-used for the PRMVA. 15

5. The RTE MAY build the MTM into a state equivalent to that reached after the completion of step 3. In 16

that case, the RTE MUST also perform the RTM/RTV functions, and so does not need to build a 17

separate RTM/RTV. (But the RTE MUST still build a PRMVA.) 18

Start of informative comment: 19

The above operations are all entirely within the TBB. The option of building an MTM into a state “as if” steps 20

2 and 4 had been run - and not building a separate RTM/RTV - might for instance be used as an optimization 21

during pristine boot. 22

The boot process then continues involving components outside the TBB. It is assumed that these components 23

will perform the tasks described below, and will communicate with the TBB using part of the abstraction 24

layer e.g. at least the TBB Interface API. 25

End of informative comment 26

6. The Boot Loader is assumed to measure (at least) the TCB of the Main OS and to perform a verified 27

extend of the measurement into the MTM. An interface to the MTM MUST already be available to 28

allow the Boot Loader to perform either an extend or verified extend and determine whether the 29

result was successful. At least an ordinal-level interface MUST be available. If successful, it is 30

assumed that the Boot Loader will start (at least) the TCB and then stop running. 31

7. The TCB is assumed to then measure (and maybe verify) other components which need to be 32

launched to complete boot. An interface to the MTM MUST already be available to allow the TCB to 33

perform either extends or verified extends, and determine whether the result was successful. At 34

least, the TBB Interface API SHOULD be available. 35

4.2.2 Run-time Operation of the TBB 37

The following steps describe the intended use of the TBB during the Engine‟s run-time: 38

1. Components of the Main OS are assumed to measure (and optionally verify) any critical applications at 39

launch. The Trusted Services API SHOULD be available, so that these components can use it to 40

perform extends/verified extends to the MTM. 41

2. Components running within or on top of the Main OS are assumed to also support run-time integrity 42

services (spot checks/alarm conditions/AV/Intrusion Detection etc.) to detect attacks on OS or on 43

critical applications. The Trusted Services API SHOULD be available, e.g. to allow these components 44

TCG Mobile Abstraction Layer TCG Copyright

Specification Version 1.0 Revision 2.03

29 April 2010 Page 18 of 117

TCG PUBLISHED

to record new run-time measurements, retrieve earlier measurements, compare old measurements 1

with new measurements. 2

3. The Trusted Services API SHOULD be available for use by other applications running within or on top 3

of the Main OS e.g. to allow these applications to use the API for creating and using keys, sealing, 4

unsealing, reading and quoting PCRs. 5

4. Occasionally, on a periodic or event-triggered basis, the PRMVA SHALL run in the Secure Execution 6

Environment. The PRMVA SHOULD at least check the status of the TCB (e.g. re-measure the Main OS 7

kernel including the SRMVA, and/or act as “Watchdog Timer”). The PRMVA SHOULD disable interrupts 8

and debugging services while performing these checks. After verifying its integrity the PRMVA MAY 9

request services from the TCB including requesting that the SRMVA verify the integrity of 10

applications. 11

4.2.3 Installations and Updates performed using the TBB 13

The following steps describe the intended use of the TBB when new applications are installed which require 14

protecting by RIMs. Where this involves the creation of a new internal RIM, then a “RIM Conversion Agent” 15

MUST be used, and it SHOULD be split between a first component (“Normal”) which runs outside the TBB, and 16

a second component (“Secure”) which runs within the TBB. 17

1. The first component is assumed to handle integration with a Device Management agent, verify any 18

external signature and certificates for the new software, and unpack the new software. 19

2. The first component is assumed to then call the second component to measure the image of the 20

unpacked software. The first component is also assumed to pass the second component a suitable 21

external RIM to be converted into an internal RIM. 22

3. Once called, the second component MUST check that the engine state is acceptable to create a new 23

internal RIM (e.g. PCR values allow unseal of the necessary verificationAuth data). The second 24

component SHALL then measure the unpacked image, and – whenever it can be directly compared 25

against the external RIM – verify that the unpacked image is as expected. The second component 26

SHALL then use the MTM to sign a new Internal RIM; thus securely recording the application image as 27

it was at install. 28

4. The first component is assumed to then register the installed software, and mark the software as 29

being protected by the new RIM. 30

If applications already protected by RIMs are modified or removed entirely, or changes to the boot sequence 31

are needed, the RIM Conversion Agent MUST be again called. The first component is assumed to call the 32

second component to re-sign the existing internal RIMs. Once called, the second component SHALL attempt to 33

re-sign all internal RIM Certs that remain valid. Once a complete new set of internal RIM Certs has been 34

successfully created by the re-signing process, the second component SHALL increment counterRIMProtect to 35

invalidate the old internal RIM Certs. 36

TCG Mobile Abstraction Layer TCG Copyright

Specification Version 1.0 Revision 2.03

29 April 2010 Page 20 of 117

TCG PUBLISHED

The less privileged environment accesses the protected environment exclusively through the defined TBB 1

Interface API, and cannot subvert the protected environment. Both environments have access to volatile 2

storage. The protected environment has access to write-once non-volatile storage in the form of ROM but has 3

no access to protected write-many non-volatile storage. The protected environment therefore always boots 4

into the same fixed state when power is completely removed and then reapplied. It then loads in 5

encrypted/integrity protected state from normal NV storage. 6

In Figure 4, the OS of the DM‟s Engine provides normal OS services and also provides isolated execution 7

environments that instantiate and isolate other trusted engines. The OS provides software compartments that 8

instantiate trusted engines A, B and C, which are isolated sets of applications and trusted services. The 9

trusted engines are built according to specifications provided by the Device Manufacturer, designed to satisfy 10

the requirements of the other platform stakeholders. 11

Applications (i.e. measured services) executing in different trusted engines are therefore isolated from each 12

other by the OS, are measured and reported via the OS, and receive TCG trusted services (such as Protected 13

Storage functions and time stamping functions) from the OS. The OS also provides AIKs for each of the other 14

trusted engines. 15

All the trusted services consumed by engines A, B and C are provided as a service by the DM‟s engine (the 16

OS). The trusted engines A, B, and C execute applications on behalf of a Communications Carrier, Service 17

Provider, and User. The Device Manufacturer‟s engine provides radio access only to the Communications 18

Carrier. The Communications Carrier engine provides network access for the Service Provider engine, and the 19

Service Provider engine provides an address book service for the User. The User engine stores the User‟s data. 20

These services are communicated via the OS, which ensures that services come from the correct source and 21

go to the correct destination. Each application is provided by the relevant stakeholder and stored in 22

unprotected NV storage in the platform during manufacture. 23

The Trusted Services API implements the mandatory functionality (and conditional mandatory functionality 24

because of the RTV) defined in Section 7. 25

End of informative comment. 26

剩余116页未读，继续阅读

书香度年华

粉丝: 1w+
资源: 383

"TCG移动领域技术规范1.0版本修订2.03"

TCG-Glossary-V1.1-Rev-1.0.pdf

MPWG-tcg-mobile-reference-architecture-1.pdf

tcg-mobile-reference-architecture-normative-requirements.pdf

TCG-Mobile-Trusted-Module-2-0-Use-Cases-v1-0.pdf

TCG-Security-Automation-Architects-Guide.pdf

TCG-TNC-Architecture-for-Interoperability.pdf

AG_BYOD-Security-Using-TCG-Technology.pdf

TCG-Comply-to-Connect-Architects-Guide.pdf

TCG-ICS-Spec-for-Network-Segmentation.pdf

TCG-DICE-Arch-Implicit-Identity-Based-Device-Attestation.pdf

最新资源