The Vault

Evolution of Trusted Systems from PCs to Mobile Devices
Research Paper / Mar 2013


Evolution of Trusted Systems from PCs to Mobile Devices
Dolores Howry

InterDigital Communications, LLC.
781 Third Avenue

King of Prussia, PA USA
011-610-878-7800

Dolores.Howry@InterDigital.com

Yogendra Shah, PhD
InterDigital Communications, LLC.

781 Third Avenue
King of Prussia, PA USA

011-610-878-7800

Yogendra.Shah@InterDigital.com

ABSTRACT
A trusted ecosystem for mobile devices based on trusted

computing principles is presented. The trusted ecosystem model

from the latest PC platform provides a foundation for the

evolution of a trust model for the diverse mobile device market.

By separating and performing fine grained access control, error

reporting and remediation and then balancing the trusted

computing burden between the mobile device and network, the

processing in the network is hugely simplified together with an

increased efficiency in the use of network resources. Certification

of the mobile device trust security capabilities provides a white

box view into a mobile device’s security architecture and a

means to gain a high level of trust assurance in the mobile

device.

General Terms
Security, Measurement, Performance, Standardization, Design,

Verification, Management.

Keywords
Trusted Computing, trusted ecosystem, device integrity, trust

certification, trusted execution environment, secure boot, access

control, remediation.

1. INTRODUCTION
Security and trust have become a top priority for PC platforms in

recent years prompting companies such as Intel and Microsoft to

strive to provide more secure platforms for their users. The

ability to ensure privacy of end user information as well as the

assurance of trusted operation of a PC is of paramount

importance in the design of future PC systems. As users move to

mobile devices (e.g. tablet computers and smart phones) and

become more dependent on the use of Internet technologies to

access data and services, the value of trust security for mobile

systems must also keep pace with the increased threats to user

data and the secure use of Internet services. Established trust

security from PC platforms may be extrapolated and then

incorporated into mobile devices to develop a complete trust

security ecosystem for mobile devices.

As wireless networks become more and more distributed, new

security threats are emerging. Endpoint protection is becoming

increasingly necessary in terms of the security architecture for

distributed networks. Unprotected network edge components are

susceptible to attacks and will require stronger security as part of

an overall network security architecture. For example, cellular

systems employ Femto cells, relay nodes and gateways to

interface with mobile devices for access to mobile networks.

These edge devices are not protected by the typical garden wall

security afforded to other network nodes, leaving them

vulnerable to multiple vectors of attack, impacting the

availability and operational aspects of the wireless networks.

Likewise, mobile device security also needs to be bolstered. Data

stored on mobile devices and the services they access require

protection. Mobile applications provide a variety of services

including services that require a significant level of security such

as online banking and mobile payments. A device infected by

malware undermines the trust assurances the user expects and

can have costly consequences to both the user and the service

provider. Innovations in the PC security model provide the

foundation for the evolution of platform trust security defined by

the Trusted Computing Group (TCG) [8]. PC security

architectures are anchored on Trusted Platform Module (TPM)

based trusted computing technologies, enabling safer and

consistent behavior that offers improved security.

Transitioning the conventional PC trust security model to a

mobile system requires an adaptation of the security architecture

since TCG techniques remain impractical from the standpoint of

application to broad consumer markets. Traditional TCG

technologies place a heavy burden on the networks to ensure the

security of the devices. Wireless network operators are already

burdened by heavy traffic volume that will only worsen as

consumers move to more and more dependence on wireless

communications for their connectivity and with the growth of the

Internet of Things. Mobile devices can benefit from the advanced

trust assurance security features architected for the PC

environment, by evolving and incorporating these into a trusted

ecosystem for mobile systems. Creation of a more practical

approach to trust security is possible by separating access control

decisions from remediation in the network and by balancing trust

processing between the mobile device and the network.

2. CURRENT PC ARCHITECTURE
The latest PC security architecture is based on the Unified

Extensible Framework Interface (UEFI) specification and TCG

technologies, utilizing hardware and software enhancements

leveraged by the Windows 8 OS framework [6]. Figure 1

illustrates the Windows 8 platform integrity architecture. A

secure boot process initiates the platform startup. The trust

assurance in the secure boot process is based on an immutable

Hardware Root of Trust (RoT). The platform incorporates a TPM

to provide a Root of Trust for Measurement (RTM) and a Root of

Trust for Storage (RTS). At boot time, the platform utilizes the

TPM to provide secure measurements and storage for various

architecture components [9]. As identified in Figure 1, the TPM

computes the measurements for the Pre-OS stage components

and then protects the measurements cryptographically for storage

outside the TPM in the measurement log file. At completion of



Stage 1, control is transferred to the kernel and an Early Launch

Anti-Malware (ELAM) component in Stage 2. Additional

measurements are taken according to policies defined for the

platform. These measurements are also protected by the TPM

and stored in the measurement log file. At the completion of the

Windows logon process the platform anti-malware (AM) client is

provided with the measurement log protected by the TPM in

Stage 3. The detailed component measurement report is then sent

to a remote entity to complete the platform attestation process in

Stage 4.

Hardware Boot

Components

Windows Kernel

Initialization

OS Boot

Components

TPM

Pre-OS

1

AM Software

Initialization

Other Initialization

Boot Driver

Initialization

Kernel-AM

Policy2

Windows Logon

AM Remote

Services
AM Client Network

Log

4
3

Measurements

Figure 1. Measured Boot and Anti Malware Components

2.1 UEFI Advantages
The PC platform architecture has been further enhanced in

Windows 8 by the mandatory implementation of UEFI based

firmware security backed by a hardware anchored RoT. The

UEFI firmware resides between the hardware and OS level,

replacing the conventional BIOS in the Pre-OS boot stage in

Figure 1. The UEFI firmware represents a collection of drivers,

OS loaders, tables and applications. It enables the measurement

and reporting of the platform firmware integrity. The UEFI

firmware provides several advantages including the provisioning

of a flexible pre-OS environment enabling applications and

drivers to execute in the boot environment with few constraints

[7][12]. Additionally, with no functional OS available, UEFI can

provide a full networking protocol stack to enable diagnostics

and firmware upgrades as well as repairs to the operating system,

by contacting and authenticating to a remote server.

2.2 Early Launch Anti-Malware (ELAM)
The ELAM feature provides a Microsoft-supported certificate

based launch of AM software prior to the loading of any third-

party components. The benefit of activating the AM drivers first

is that loading of subsequent drivers is under the control of the

AM software. The ELAM is the first application loaded by the

OS and controls the staged bring-up of the remaining

applications on the platform. The ELAM provides the platform

an ability to control the loading of applications whose integrity

may be in question, as assessed through direct integrity checks of

the firmware and certificates. The ELAM boot driver

measurements are stored in the TPM for later attestation with a

remote AM server.

2.3 Anti-Malware Client
The AM client on the platform is the component that works in

conjunction with the ELAM software to facilitate measurement

reporting. The AM client provides communication with a remote

AM server. The AM client sends a log of the measured

components, collected during the boot process and stored in the

TPM, to the AM Server for remote attestation. The stored

measurements include measurements taken in the Pre-OS stage,

facilitated by UEFI firmware, as well those taken by the ELAM.

The report provided by the AM client contains detailed

component information that is specific to a particular platform.

3. MOBILE DEVICE TRUST SECURITY

ARCHITECTURE

3.1 Practical Limitations
Standard platforms such as PCs have a security architecture

based on TCG technologies. The traditional TCG Trusted

Network Connect (TNC) architecture [11] requires the network

to obtain detailed knowledge of the platform component

measurements, which enables both access control and

remediation. The network must process the reported component

measurement log, from the PC platform, to assess the state of the

platform in order to make an access control decision, a task

similar to a remediation process. This process results in a

heavyweight communications interface between the platform and

the network with extensive processing on the network side.

Though this burden may not be of great concern in PC based

architectures, a migration to high volume consumer markets such

as mobile devices reporting such measurements would place a

tremendous traffic and processing burden on the network.

Furthermore, with hundreds of mobile devices currently available

and new handset designs coming onto the market every 12 to 18

months, the task of maintaining component measurement

databases becomes impractical.

While the TCG TNC technologies have merit in a standard

Intel/Microsoft Windows based PC architecture, the same does

not apply to mobile phone platforms where there is a large

diversity of processors and architectures. Mobile devices have

many varieties of hardware architectures with each chipset

manufacturer having a proprietary processor architecture which

included various ARM variants, Intel ATOM, TI OMAP,

Qualcomm Snapdragon, etc. Therefore the network operator

lacks external visibility into a mobile platform’s proprietary

security architecture and how a particular manufacturer has

implemented trust security capabilities in their mobile platform.

In addition, no evaluation criteria exist to determine the security

architecture of a device or how a secure boot process has been



Permission to make digital or hard copies of all or part of this work for

personal or classroom use is granted without fee provided that copies are

not made or distributed for profit or commercial advantage and that copies

bear this notice and the full citation on the first page. To copy otherwise, or

republish, to post on servers or to redistribute to lists, requires prior specific

permission and/or a fee.

Conference’10, Month 1–2, 2010, City, State, Country.
Copyright 2010 ACM 1-58113-000-0/00/0010 …$15.00.





implemented, resulting in a low level of trust assurance in the

mobile device.

3.2 Evolution of PC Trust Security to Mobile

Devices
Decoupling the access control decisions from the remediation

function and distributing the trust processing between the

network and mobile device in a balanced manner provides for an

improved trust processing and access control mechanism.

Evolution of the PC trust security model to such device trust

assessment architecture requires adaptation of the TCG approach

to measurement and reporting. Equipping the mobile device with

the ability to measure the security state of the platform in a

trusted manner and report information suitable for access control

policy decisions reduces the burden the network operator.

Platform validation is the ability for a device to measure its own

“health” (or its integrity) and report the results to the network

operator to efficiently assess the trust state of the platform.

Following an access control decision, failure reports are

forwarded to the device management server. Blending the

remediation function into the device management (DM) server,

where intimate knowledge about the device configuration already

exists, provides for a more efficient mechanism for detailed

platform remediation.

Similar to the UEFI and measured boot process in a PC

architecture, platform validation is a process where a secure boot

brings-up the platform through performing a series of trustworthy

self-checks on components of the system and then reports them to

the network to complete the trust assessment and perform access

control decisions. The mobile device performs secure self-

administration of policy based component load control and

validation measurement reporting as part of the secure boot

process, which simplifies the reporting of trust state information

and reduces the burden on the network in performing an

assessment of the trust state. Moreover, the network can notify

the device management server to trigger remediation of a

compromised device. The device management server can further

interrogate the mobile device to isolate component failures

reported during the access control process to perform remediation

under conditions that are beneficial for both the device and the

network load.

The proposed mobile device trust security architecture distributes

trust based processing on two core conceptual elements - a secure

boot process anchored on a hardware RoT and a secure execution

environment (SEE) for trust measurement, evaluation and

reporting. The secure execution environment is an environment

that can be trusted to perform security sensitive operations and

store data securely. The ARM Trust Zone is an example of a

prime candidate for inclusion in the mobile device architecture.

The Mobile Trust Module (MTM), which is a TPM tailored for

mobile applications, and the Global Platform Trusted Execution

Environment (TEE) [5] are other suitable technologies. The

Trusted Software Stack (TSS) that provides a standardized API

to access the TPM is another technology that can be adapted

towards the mobile embedded system environment [10].

Finally, the lack of visibility into the mobile device security

architecture can be addressed through white box certification.

Certification provides a means to circumvent the issue of

visibility into the security architecture and secure boot process

giving network operators a higher level of trust assurance for the

mobile device.

4. ELEMENTS OF PROPOSED TRUST

SECURITY ECOSYSTEM
Figure 2 provides a view of an ecosystem for remote trust

assessment in mobile devices. At the heart of the mobile

device trust security is a Trust Module incorporating a

SEE anchored on an immutable hardware Root of Trust.

This provides the core architectural basis for the mobile

device trust security model. The strength of the Trust

Module is its ability to execute a policy based platform

bring-up through a chain of trust. The secure mobile

device incorporates independently certified hardware and

software components enabling external entities such as the

network operator to establish trust in the device. A

certified hardware Trust Module provides a layered

approach to device trust certification and a path to meet

the rapid development cycles for products targeted towards

the mobile market. Certified software components provide

additional means to establish trust in the devices to remote

entities.

Phone Design
using Trust Module

Cert
Cert

Certification

Authority

Cert

Certified

Trust Module

Trust Module

IP Block

Independent

Testing

Build Release

Code Design/
Development Code/Trusted

Ref Values

Code

Cert

Certified Code &

Trusted Ref Values

Secure
Platform

PVE/AAA/HSS

DM Server

Measurement

Report Meas. Data
Credentials

Figure 2. Ecosystem for Establishment of Trust in Mobile

Devices

The second element of the trusted ecosystem is the access control

entity. In a cellular wireless system the proposed access control

entity is called a Platform Validation Entity (PVE). The PVE can

be considered an extension to the wireless network’s

Authentication, Authorization and Accounting (AAA) and Home

Subscriber Server (HSS) function and tightly coupled with

authentication procedures. The role of the PVE is to validate the

trust state of the mobile device and make fine-grained access

control decisions based on the results of the integrity checking

measurements and certification information obtained from by the

mobile device. The result of the validation process enables

service and content providers to gain trust in the mobile device to

provide the requested services and content. A description of the

reported functionality is provided in section 5.4.

The third element in the trusted ecosystem is the device

management server. When performing device validation, in the

event of a measurement report indicating a failed functionality,

the PVE informs the device management server of the failure.

The device management server is enhanced to perform



remediation through interrogation with the device management

client on the mobile device to isolate specific failed software

components and provide secure software updates. A detailed

description of the remediation process is provided in section 5.5.

5. SECURE MOBILE DEVICES
Moving beyond the current mobile architectures, the secure

mobile device design provides trust assurance through a white

box view into the internal security architecture of the mobile

device, traceable to trusted third parties. The high level of trust

assurance is achieved through a defined trust evaluation and

certification process for both hardware and software. The

integration of certified hardware and software elements enables

the delivery of secure and trusted mobile devices. Pre-

certification of hardware and software enables mobile device

manufacturers to develop trust certified products while

maintaining the rapid development cycles for a diversity of

mobile products.

5.1 Trust Module Certification
In order to establish trust in a mobile device, the security

architecture of the platform needs to be understood and assessed.

Establishing trust in a mobile device requires an ability to peer

into the platform trust security processing including the RoT and

trust measurement and reporting capabilities. Trust in the Trust

Module may be obtained through an independent trusted third

party test and certification authority. The Trust Module is

capable of performing trusted measurements, secure storage and

maintains the ability to trigger alarms and send reports to the

network based on the integrity check results in the event of

unavailability of a full protocol stack, much like the UEFI in a

PC architecture. Additionally, the device management client is

tightly integrated into the trust system to enable remote network

driven interrogation and remediation.

The certification of the Trust Module can be executed prior to

and independent from the design of the secure mobile device.

Independent hardware testing and certification creates a white

box view of the Trust Module security which can be done in

parallel to the software certification process. In many cases a new

mobile device may not require a new trust module so by layering

the certification process for the mobile devices, manufacturers

can use pre-certified elements to build new platforms leading to

faster time to certification for the end product.

5.2 Software Certification and Signing
Similar to the hardware certification process, the software

certification and signing process also contributes to the complete

white box view of the mobile device’s trust security architecture.

The certification process includes the hashing of software

components to be integrity checked and embedding the signed

values in the form of trusted reference values (TRVs), which are

typically a cryptographic hash of a code block, into the code

release. As in the case of the hardware certification, independent

software testing and certification provides trust assurances of the

complete software security architecture.

The integrity validation procedures require the software to be

compared to TRVs. Similar to the certified measurement of the

RoT in a secure boot operation, the trusted reference values are

the expected results of the measurement of a software

component. The software Integrated Development Environment

(IDE) and Build Release tools are enhanced to provide an

automated mechanism for embedding trust information into

software releases. The software build and code release tools

enable the device processor to extract trust information for

software integrity checking and error reporting [4]. The boot and

program loader use the TRV information embedded in the code

image/components during the build process to perform integrity

check measurements and compare to expected measurements.

Measurements are compared to the embedded TRVs and the

measurement results are logged and associated with functions

being tested through tracing a software component to a function.

5.3 Trusted Assurance through Measurement

Reports
The combination of hardware and software certification

processes on the mobile device enables the network to obtain a

detailed view into the security architecture of the device.

Therefore the ability to provide detailed security architecture

information of the mobile device mirrors the security architecture

for Windows 8 based PC platforms. This information can be used

by the Mobile Network Operator (MNO) to establish trust in a

particular mobile device through evaluation of the certification

and tracing back to the trusted third parties and certificate

authorities. In the proposed method the secure platform extracts

embedded trusted reference values and uses the trust module to

verify the integrity of the hardware and software. The secure self-

measurement result reporting along with hardware and software

security credentials establishes trust between the device and

MNOs. The proposed measurement reports differ from the

traditional TCG measurement logs. Instead of sending a

measurement log or a list of component hashes for the network to

further evaluate, a list of platform functionalities is reported.

Each functionality maps to a collection of measureable

components. For example, an integrity check failure of software

components of a Netflix application will result in a failure result

being reported for the Netflix functionality.

This mapping process from a specific component to a function

enables the device to send a platform independent “self-health

check” with trust assurances provided by the security certificates

to enable the network to perform a platform trust validation and

an access control policy decision. This process replaces the

network centric TNC attestation process with a balance of trust

measurement and assessment between device and network. The

network does not need to perform attestation on a reported

measurement log in order to perform an access control decision.

In moving from a remote attestation process to a more

autonomous attestation procedure reduces network traffic and the

network processing burden [2]. More importantly the need for

the network to have a detailed knowledge of the process involved

in creating a measurement log are hugely simplified by having

the mobile device perform this task itself.

5.4 Trust Measurement and Fine Grained

Access Control
The certification process defined earlier enables the mobile

device to send trusted measurement reports to the network that

enable the network to make fine-grained access control decisions.

The measurement reports differ from traditional attestation



reporting in TNC in that there are no measurements sent in the

report, rather the status of the integrity check. As part of the

secure boot process, the device performs local measurements of

software components. Each component measurement is compared

to the corresponding TRV and a pass or fail result is stored in the

secure execution environment. The trust module applies pre-

installed policies to enable loading of software components based

on the trust measurements. Components that have failed the

integrity check are not loaded and marked by the trust module as

failed. At the completion of the secure boot process, the device

sends the measurement report to the network as part of the

authentication process. The measurement report does not contain

a measurement log as in traditional remote attestation, but rather

a list of failed functionalities represented through a mapping of

failed components [3]. The notion of component to functionality

mapping can be viewed as a physical to logical view of the

software as shown in Figure 3. The physical view corresponds to

the representation of the components in the devices memory map

which includes a start address and a size. The logical view maps

a group of components to the corresponding functionality

performed. For example, the Netflix application can comprise

numerous measureable components that support the Netflix

functionality on the mobile device and any one of these

components may be compromised and fail an integrity check. It

should be sufficient for an access control entity to know that the

NetFlix application was compromised rather than the specific

component of the NetFlix application. This approach distills the

detailed measurements into sufficient information to enable

access control decisions to be completed and at the same time

relieves the network from performing a detailed analysis of the

measurement log to identify the severity of an integrity check

failure and then apply access control policy decisions.

The mapping of component to functionality may not have a one to

one correspondence, but rather multiple components can map to

the same functionality. The component mapping can be device

manufacturer specific since each device can have a unique

component build and memory allocation which represents a

standard functionality across many mobile devices. The network

operator may define the device policies regarding loading and

reporting of failed functionalities and actions to be taken when

encountering an integrity check failure of a component. The

functionalities supported by the mobile device can be grouped to

define a policy required for the trusted and non-trusted execution

of the device as defined by the network operator. For example,

the mobile device may execute trusted and non-trusted

applications in separate environments. The result of the integrity

checking enables gating of components to be loaded.

Components that pass integrity checks are considered trusted,

while those that fail integrity checks are considered non-trusted.

Applications can consist of multiple components but identified

by the functionality they provide. The identification of

functionality enables a level of abstract reporting from the mobile

device without providing unnecessary details of the component

specifics to the network. The results of the integrity

measurements are securely reported along with detailed

certification information to an access control entity in network.



Figure 3. Functionality to Component Mapping

At the end of the boot process, the OS loader performs a

translation from software component to functionality and reports

a detailed functionality measurement report to the Platform

Validation Entity (PVE) in the network including the hardware

and software certification information [1]. Providing the network

with the security capabilities of the mobile device assures the

network that the mobile device can be trusted to perform a secure

platform bring-up and that the reported information is

trustworthy.

The PVE uses the fine-grained trust evaluation report to establish

trust in the device and provide access control information to the

network. The access control options may include granting full or

partial access to content and services or to quarantine the device

(no access) and subsequently perform remediation. The network

does not receive any detailed information regarding the

measurements of components on the device but rather a logical

report on the “health” of the device anchored by a hardware

anchored RoT. This information is sufficient to perform access

control on a mobile device without burdening the network.

5.5 Efficient Device Management and

Remediation
In addition to making access control decisions, the PVE may also

contain policies that can trigger or schedule remediation

procedures in the case of a failure report. In the event

remediation is triggered, the PVE forwards the trust

measurement report to the device management server that

reverse maps the functionality measurement errors to a set of

components on the device. Embedded trust measurement

information in the code build process allows the device

management server to readily identify failed components and

remediate only the failed components. The device management

server in turn performs additional interrogation of the device to

isolate the specific failed component(s). The device management

client on the mobile device is tightly coupled to the trust system

architecture, which enables the device to provide additional

trustworthy integrity measurements at the request of the device

management server. The device management server may chose to

provide a full component update or to further interrogate the

device to isolate errors. These additional integrity measurements

enable the device management server to isolate specific

subcomponents of the failed component. In many cases the

overhead incurred in the interrogation process may be smaller

than a full component update making the process more efficient

in terms of traffic overhead than a complete component update.

Figure 4 illustrates the access control and remediation aspects of

the ecosystem.



PVE/AAA/HSS

Mobile Device

Cert
Cert

Component View

Functionality Fn

Functionality F1

...

Functionality Fk

...

...

...

M0 ... ...

... ... ...

... ... ...

... ... ...

...

...

...

Mx

Functionality View

Functionality Fm

...

...

Firmware

Software
Components

X

Device Firmware and Software Mapping

M
an

ag
ed

O
bj

ec
ts

X

Component Failure

Detected

Fa
ilu

re
R

ep
or

t

Report

Request SW

Updates

Code Build

Release

DM Server

Certified Code &

Trusted Ref Values

Functionality Fn

Functionality F1

...

Functionality Fk

...

...

...

M0 ... ...

... ... ...

... ... ...

... ... ...

...

...

...

Mx

Functionality Fm

...

...
X

Functionality to Component

Mapping

X

X

Figure 4. Device Measurement Reporting and Remediation

6. SUMMARY OF BENEFITS
The trusted ecosystem described in this paper provides numerous

benefits for the various system stakeholders. Migration PC

trusted platform architecture to a secure mobile device provides

the core architectural basis for an embedded mobile device trust

ecosystem. Trust in a mobile device is created through a white

box view, anchored on an immutable and verifiable hardware

Root of Trust that is assured through independent testing and

certification of the platform security architecture. A layered

certification process enables platform developers to achieve the

aggressive time to market requirements for mobile devices

through a faster end product certification. Remotely configured

policies, governed by the network operators, allow flexibility in

trust establishment during the early stages of platform bring-up.

A distributed and balanced trust measurement capability where

the device performs a trustworthy self-assessment along with

higher level measurement reporting to the network unburdens the

network in terms of processing and radio resources. The mobile

device provides the proof of self-test and compromised

functionality in a measurement report to facilitate the network to

perform decisions on fine-grained access control and service

provisioning. Furthermore, the reporting of failed functionality

instead of failed components reduces the size of the measurement

reports and enables the separation of the access control function

from the remediation process. On the device side, the device

management client is tightly integrated into the trust system to

enable remote network driven interrogation and remediation. The

device management server utilizes the measurement report from

the Platform Validation Entity to perform targeted interrogation

to identify which specific software components are compromised

and then to perform efficient remediation. The overall approach

results in a lightweight network protocol, simplified network

processing, and reduced down time for mobile devices.

7. REFERENCES
[1] A. U. Schmidt, A. Leicher,, I. Cha, Shah, Yogendra, 2010,

Trusted Platform Validation and Management, In

International Journal of Dependable and Trustworthy

Information Systems (IJDTIS).

[2] A. U. Schmidt, A. Leicher,, I. Cha, 2010, Scaling Concepts

Between Trust and Enforcement, Z. Yan(Ed.), Trust

Modeling and Management in Digital Environments: From

Social Concept to System Development, IGI Global,

Hershey, PA, USA, 20-57.

[3] Cha, Inhyok, Shah, Yogendra, Schmidt, Andreas U.,

Leicher, Andreas, and Meyerstein, Mike, 2009, Trust in

M2M Communications: Addressing New Security Threats.

IEEE Vehicular Technology Magazine.Vol. 4 Issue 3, 69-

75.

[4] DuVarney, Daniel C., Bhatkar, Sandeep, and

Venkatakrishnan, V.N. 2003. SELF: a Transparent Security

Extension for ELF Binaries. In Proceedings of the 2003

workshop on New Security Paradigms. (Ascona,

Switzerland, August 18 - 21, 2003).

[5] Global Platform Device Technology, December 2011, TEE

System Architecture, Version 1.0.

[6] Microsoft Corporation, September 13, 2011, Trusted Boot:

Hardening Early Boot Components against Malware.

[7] Microsoft Corporation, March 28, 2012, UEFI and

Windows.

[8] Trusted Computing Group, 2007, TCG Architecture

Overview, Specification Revision 1.4.

[9] Trusted Computing Group, , 2008, TCG Infrastructure

Working Group, Architecture-Part II- Integrity

management, Specification version 1.0 Revision 1.0.

[10] Trusted Computing Group, 2011, TCG Mobile Abstraction

Layer, Specification Version 1.0 revision 2.03.

[11] Trusted Computing Group, 2009, TCG Trusted Network

Connect (TNC) Architecture for Interoperability,

Specification 1.4 Revision 4.

[12] UEFI, 2011, Unified Extensible Firmware Interface

Specification, Version 2.3 Errata E, April 26, 2011.