Trusted Mobile Devices: Requirements For A Mobile Trusted .
Trusted Mobile Devices: Requirements for aMobile Trusted Platform ModuleKathleen N. McGilln recent years, mobile devices have replaced desktop PCs as the computingplatform of choice for many users. Unfortunately, most mobile devices lack thesecurity measures, such as hardware roots of trust, available in more traditionalbusiness-class computing platforms. Researchers at APL are working with the TrustedComputing Group (TCG) to develop specifications for trusted computing technologiesin mobile devices. These technologies will enable desirable security properties, such asdevice integrity and protected storage, in mobile devices. In this article, we provide ananalysis of the difficulties that must be overcome by those specifications. We describekey features of trusted mobile devices: roots of trust, the Trusted Platform Module(TPM) Mobile host environment, and the Secure Boot mechanism. We present andanalyze an example implementation of a near-term trusted mobile phone. Finally, weoutline the TPM Mobile roadmap to bring trusted mobile devices to market.INTRODUCTIONIn recent years, mobile devices have replaced desktopPCs as the primary computing platform for many users.This trend is encouraged by convenient access to bankaccounts, personal networks, and a wide range of networked resources through our tablets and mobile phones(see Fig. 1). Many organizations would like to use mobiledevices in the work environment as a cost-savings andefficiency measure. Organizations may also wish to allowemployees to use their personal mobile devices to accessenterprise resources, an initiative commonly called“Bring Your Own Device.”544Because most mobile devices lack the security measures available in more traditional computing platforms,enterprises are concerned about associated risks of integrating mobile devices into their networks. For example,most mobile devices do not include the hardware rootsof trust that are built into traditional business-class platforms. These hardware roots of trust are the foundationof trust in any platform and enable security properties forprotection-conscious enterprises that wish to use them.The National Institute of Standards and Technology (NIST) recommends a set of desired capabilities forJOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 32, NUMBER 2 (2013)
evaluates this evidence to determine whether the device is in anexpected state. If the appraiser issatisfied, the attestation passes,and the appraiser grants access tothe resource. This scenario andits variants are frequently usedwithin enterprises and the U.S.government to control access totheir networks.Many traditional businessclass computing platforms provide desired security capabilitiesthrough a hardware root of trustcalled the Trusted PlatformModule (TPM). A TPM is a discrete hardware component ofa platform that provides securegeneration and management ofcryptographic identities, isolatedprocessing resources, and protected storage for sensitive data.3The TPM specification was develFigure 1. Mobile phone applications for enterprise and banking services. (Image on leftoped by the Trusted Computingreprinted from Ref. 1.)Group (TCG), an internationalsecurity-enabled mobile devices2: device integrity, isoboard that aims to define and promote open industrylation, and protected storage. A device has integrity ifstandards for interoperable trusted computing platforms.4its software, firmware, and hardware configurations areA TPM bolsters an attestation by vouching for thein an expected state. Device isolation provides separateauthenticity of the measurement data and binding theattestation to a particular device and its software condomains for computations and data owned by differentfiguration. The TPM storage protects measurement dataentities, or stakeholders, on the same device. Protectedcollected on the device. Typically, these data includestorage enables mobile devices to protect the confidenhashes of the software that booted on the device. Thetiality and integrity of data on the device while in useTPM can provide a report of the measurement data forand at rest.2an attestation and sign the data with a private attestaA mobile device should be able to provide evidence oftion key protected by the TPM. The attester providesdevice integrity to a third party by some form of devicethe signed data and a credential for the TPM attestationattestation.2 An attestation may be described as a claimkey to the appraiser. This credential allows the appraisermade by a device, the attester, about its properties to ato verify the authenticity of the measurement data andthird party, an appraiser, and provides evidence to supto verify that the private key used to sign the data isport that claim. The appraiser makes a decision aboutprotected by a genuine TPM.the attester based on the provided evidence. Figure 2displays a common device attesAppraiser:Protectedtation scenario. The attester is aremote serverresourcesAttester:mobile device that seeks accessmobileto some protected resource. The(i) Request accessdeviceappraiser is a remote server thatserves as a gatekeeper for the pro(ii) Device attestationtected resource. First, the devicerequests access to the resource.(iii) Attestation passesThe appraiser requires a deviceattestation. In this attestation, themobile device will provide some(iv) Access grantedmeasurement data, which represent the state of the device as evidence of its integrity. The appraiserFigure 2. Device attestation.JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 32, NUMBER 2 (2013)545
K. N. M C GILLMany mobile devices have space, power, and cost constraints, which have hindered the adoption of a discreteTPM chip. However, recently, new mobile technologieshave emerged, enabling alternative implementationsof the traditional TPM chip in the mobile arena. Forexample, the ARM TrustZone technology uses hardware mechanisms to partition the device into secure andnonsecure resources.5 Similar to a TPM, these mechanisms may be capable of protecting trusted componentswithin the secure resources.Researchers at APL are working to enhance existing specifications for trusted computing technologiesin mobile devices. APL is working within the MobilePlatform Working Group to specify a mobile adaptationof the TPM—called the TPM Mobile—and a ReferenceArchitecture. The objective of this work is to encouragetrusted mobile computing technologies in the market.This goal targets the growing need for trusted mobiledevices at APL, within the U.S. government, andthroughout the nation.This article provides an introduction to the TPMMobile requirements and an analysis of the problemssuch a specification must overcome, with an emphasis on APL’s contributions. The article begins with anintroduction to trust concepts in mobile devices. Thearticle presents definitions for mobile roots of trustthat were developed in collaboration between APL andmembers of the U.S. government. Then key features oftrusted mobile device architectures are described: theTPM Mobile, its host environment, and secure boot ofthe mobile device. APL drafted the host environmentsection in the Reference Architecture specification andworked with members of the Mobile Platform WorkingGroup to resolve issues that would impact market adoption. Finally, the article presents an example and analysisof a TPM Mobile that is implemented using a combination of hardware, firmware, and software. APL developed this model for use in the final specification to serveas an example for implementers. The model is also usedto demonstrate issues the specification must resolve.process that includes cryptographic owner authentication of the root of trust or a secure local mechanism.Finally, a root of trust should include as minimal functionality as is possible to reduce the attack surface oftrusted code.2The following roots of trust provide the security capabilities of a trusted mobile device.TRUST CONCEPTSRoots of TrustThe security services of a mobile device are enabledby roots of trust. A root of trust is a hardware, firmware,and/or software component that is inherently trustedto perform security services on a device. Roots of trustmust behave as expected because their misbehaviorcannot be detected.6 For this reason, roots of trust mustbe designed securely. There must be mechanisms inplace to protect the roots of trust from unintentionalor malicious action. If a root of trust can be modified,those modifications must be made using a secure update546 Root of trust for confidentiality (RTC): The RTCprovides locations for protecting confidential datasuch as private keys and random number generatorstates. It also must include a protected interface thatrestricts access to and modification of these data.2 Root of trust for integrity (RTI): The RTI provideslocations for protecting integrity-sensitive data. Italso includes an interface that restricts access tointegrity parameters. The most significant differencebetween the RTI and the RTC is that the RTC protects secrets while the RTI protects values that aremeant to be shared. They require different authorized interfaces. In traditional TCG terminology,the RTC and the RTI combine to form the root oftrust for storage.2 Root of trust for reporting (RTR): The RTR provides authenticity and nonrepudiation services foruse in attestation. This is typically represented bya signing key that is unique to the device. A typicaluse of the RTR is to sign integrity data during anattestation of the device. Root of trust for measurement (RTM): The RTMperforms integrity measurements on the device.Usually, an RTM measurement is a cryptographichash of a software image. Root of trust for verification (RTV): The RTVverifies the integrity of software and data. Thiscan be done either with a digital signature using apublic key stored securely on the device, or by comparison against reference values stored securely onthe device. Root of trust for update (RTU): Because it isimpractical to ship commercial devices without ameans of updating them in the field, a means mustbe available to secure the update mechanism used onroots of trust. The RTU must verify that an update isauthentic and not allow an update to proceed unlessan update is verified. Additionally, it must provideprotection against unauthorized rollback of updates,once installed.Figure 3 displays an example of the interactionsbetween the roots of trust that provide services to support an attestation. First, the RTM performs an integritymeasurement of some piece of software on the device.JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 32, NUMBER 2 (2013)
REQUIREMENTS FOR A MOBILE TRUSTED PLATFORM MODULEThis measurement may occurduring the boot cycle or uponrequest after the device hasApplicationApplicationbooted. The RTM stores themeasurement in the RTI. Duringan attestation, an application36on the device requests a signedreport of the integrity emment from the RTR. The RTRmeasurementreportretrieves the integrity measurement from the RTI and signs themeasurement with the identityRoots of trustin the RTC. Finally, the RTR1 Measurereturns the signed measurementSign measurement5to the requesting application foruse in the attestation.Ideally, roots of trust areRTIRTCRTVRTRRTURTMimplemented in dedicated hardware, or at least protected byhardware mechanisms. Dedicated hardware, such as TPM 1.22 Store measurement4 Retrieve measurementimplementations, are hardwarethat are only used by designatedentities and are isolated fromother entities of the device.Figure 3. Root of trust interactions for an attestation.Initial TPM 2.0 implementations today are run from firmware—sometimes as an application running TrustZone.Because TrustZone runs on the same CPU as the mainapplication space, this requires a shift in emphasis forTPM Mobile from requirements of dedicated hardwareto requirements of the properties of TPM Mobile’s hostTrusted servicesenvironment and mobile roots of trust. This shift willin softwareenable alternative implementations of trusted mobiledevices with minimal dedicated hardware.Measure,verify,executeTrusted servicesin firmwareMeasure,verify,executeTransitivetrustRoots of truststored in boot ROMExecuteHardwareroot of trustBoot ROMFigure 4. Transitive trust in mobile devices. ROM, read-onlymemory.JOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 32, NUMBER 2 (2013)Transitive TrustTransitive trust is crucial to enabling alternativeimplementations of trusted mobile devices. A root oftrust can delegate its services to another entity on thedevice. In this case, a root of trust provides a transitivechain of trust to the entity to establish trustworthinessof that entity. In order to extend a transitive chain oftrust to an entity, the entity must first be measured andverified by a trustworthy entity. These delegates of theroots of trust are referred to as trusted services. Figure 4displays a notional transitive chain of trust. The transitive trust begins with a hardware root of trust, such ascode in ROM of the device. The code in ROM measuresand verifies the next piece of code in the boot cycle,such as other firmware. After the firmware is verified,it is allowed to execute. This measure–verify–executesequence continues as each code module measures andverifies the next code module before passing execution.547
K. N. M C GILLThe transitive trust extends as far as this sequence isapplied. Transitive trust enables flexibility in implementing trusted services. The roots of trust can delegateservices to other entities on the device while preservingthe trustworthiness derived from the original hardwareroot of trust.TPM MOBILE ARCHITECTURETPM MobileThe challenge of the TPM Mobile specification isto adapt the TPM 2.0 specification for mobile devices.The goal of the TPM Mobile specification is to enableimplementation on a wide range of mobile devices,6 andmuch of this goal will be achieved by clearly definingrequirements of the architecture in which the TPMMobile is deployed. Whether a TPM implementationis implemented in hardware or in firmware, isolation ofthe TPM implementation must be maintained—it musthave its own execution and memory resources to preventexposure of secrets that it is tasked to maintain.A defining feature of mobile devices is that thereare usually multiple stakeholders on a single device—each demanding private data and processing resources.This can be achieved in a TPM 2.0 environment in twoways—either by using separate key chains rooted inseparate storage root keys that coexist on the TPM orby having several TPM implementations on the samedevice. To maintain compatibility for software createdto be used on personal computers or mobile devices, theTPMs instantiated on those devices must also be compatible. Therefore, if multiple TPM implementations areto be used, it is important that one of those TPMs be setapart to be used for attesting to the device integrity andthat this TPM be compatible with existing server anddesktop systems that use TPMs.Host EnvironmentThe host environment of a TPM is the isolatedexecution environment in which it runs. The isolatedexecution property of the host environment distinguishes it from the device environment as a whole. Inthe case of the discrete TPM chip, the chip is the hostenvironment. In cases where isolation is implemented inhardware and/or software, the architecture of the devicedetermines one or more host environments within thedevice. The roots of trust of the device reinforce thehost environment by supporting the required properties.NIST has published those requirements that must bepresent to provide hardware rooted security in a TPMMobile host environment.2 The implementation of thehost environment may take any form provided that itsatisfies these requirements.548Minimum Requirements of a TPM Mobile Host EnvironmentThe following are requirements for a TPM in a mobilehost environment. These requirements can be met witheither a hardware or software TPM.1. The TPM’s execution environment must interfaceonly with other execution environments throughstandard protected interface APIs, as defined in theTPM 2.0 specification. This protects TPM resourcesduring execution.2. The TPM must have a unique cryptographic identity. This is necessary to prevent spoofing duringattestation.3. The TPM must have a means of protecting itsresources when it is not executing. No untrusted orunverified code should have access to TPM secrets.4. The TPM must have a means to prevent rollback ofits resources when it is not executing.5. The TPM must be uniquely attached to the device.This is necessary to allow the TPM to performdevice attestation.6. The TPM must have its code integrity protectedwhile it is executing. This requires a strong hostenvironment isolation mechanism.7. The TPM must have its code integrity protectedwhile it is not executing. This is typically done byverifying the integrity during initial program load ofboth the TPM code and any other code that must betrusted with TPM secrets.8. The TPM must provide a mechanism that allowsattestation of the version of both TPM code and anyother code that must be trusted to maintain TPMintegrity.9. The execution environment must provide resourcesnecessary for the TPM to meet the requirements ofthe TPM 2.0 specification.Implementation OptionsSeveral implementation options are available for aTPM Mobile and its host environment. We typicallyrefer to different implementations as “hardware,” “software,” or “firmware” implementations. Although allimplementations include software/firmware and thehardware on which it executes, these terms aim to differentiate the amount of dedicated hardware in eachimplementation. In general terms, we differentiate firmware from software by where it is stored on the device.Firmware is typically stored in nonvolatile ROM.A hardware of firmware implementation of a TPMMobile provides the best security. A software TPMMobile shares the same processing resources as therest of the mobile device. Any isolation properties areJOHNS HOPKINS APL TECHNICAL DIGEST, VOLUME 32, NUMBER 2 (2013)
REQUIREMENTS FOR A MOBILE TRUSTED PLATFORM MODULEachieved through software virtualization mechanismsin the operating system (OS) or hypervisor and arebased on trust that the operating system or hypervisoritself provides. There is skepticism within the trustedcomputing communities that this approach can provide the necessary security capabilities. Trust must beplaced in a complex software solution that supports thegeneral purpose of the device as well as the trusted services of a TPM Mobile. History has shown that generalpurpose software is likely to include bugs, which leadto unexpected software states. It is usually infeasibleto verify that software of this complexity will behaveas expected.Hardware TPM MobileThe hardware TPM Mobile is a traditional TPM chip.The TPM Mobile includes a dedicated processor andstorage resources that are physically distinct from theother resources of the device. This physical distinctionprovides protection from other resources on the deviceand allows for certification of the TPM independent ofthe rest of the device. The main disadvantage of thehardware TPM Mobile is the requirement of dedicatedhardware in a resource-constrained device.on the processor context. Monitor software controlscontext switching between the normal and secureworlds. The end result is an isolation boundary betweenthe normal and secure worlds that resembles a dedicatedhardware solution.GlobalPlatform, another international standardsboard, has developed a specification for implementing anisolated execution environment, called a Trusted Execution Environment (TEE).7 A TEE is an execution environment that runs on the same hardware as the RichExecution Environment (REE). The REE is a more versatile environment, such as the Android environment,with support for a wide range of application features. TheGlobalPlatform TEE is specified with a set
oped by the Trusted Computing Group (TCG), an international board that aims to define and promote open industry standards for interoperable trusted computing platforms.4 A TPM bolsters an attestation by vouching for the authenticity of the measurement data and binding the attestatio
Bruksanvisning för bilstereo . Bruksanvisning for bilstereo . Instrukcja obsługi samochodowego odtwarzacza stereo . Operating Instructions for Car Stereo . 610-104 . SV . Bruksanvisning i original
10 tips och tricks för att lyckas med ert sap-projekt 20 SAPSANYTT 2/2015 De flesta projektledare känner säkert till Cobb’s paradox. Martin Cobb verkade som CIO för sekretariatet för Treasury Board of Canada 1995 då han ställde frågan
service i Norge och Finland drivs inom ramen för ett enskilt företag (NRK. 1 och Yleisradio), fin ns det i Sverige tre: Ett för tv (Sveriges Television , SVT ), ett för radio (Sveriges Radio , SR ) och ett för utbildnings program (Sveriges Utbildningsradio, UR, vilket till följd av sin begränsade storlek inte återfinns bland de 25 största
Hotell För hotell anges de tre klasserna A/B, C och D. Det betyder att den "normala" standarden C är acceptabel men att motiven för en högre standard är starka. Ljudklass C motsvarar de tidigare normkraven för hotell, ljudklass A/B motsvarar kraven för moderna hotell med hög standard och ljudklass D kan användas vid
LÄS NOGGRANT FÖLJANDE VILLKOR FÖR APPLE DEVELOPER PROGRAM LICENCE . Apple Developer Program License Agreement Syfte Du vill använda Apple-mjukvara (enligt definitionen nedan) för att utveckla en eller flera Applikationer (enligt definitionen nedan) för Apple-märkta produkter. . Applikationer som utvecklas för iOS-produkter, Apple .
2.3 Trusted Computing The Trusted Computing Group (TCG) [10] proposed a set of hardware and software technologies to enable the construction of trusted platforms. In particular, the TCG proposeda standardforthe design of the trusted platform module (TPM) chip that is now bundled with com
TC Trusted Computing TCG Trusted Computing Group, group of companies developing the TC specs TCPA Trusted Computing Platform Alliance, predecessor of TCG TPM Trusted Platform Module, the hardware Palladium, LaGrande, implementations from various companies, are not always
.3 ISA / ANSI, ANSI-A300, Standards for Tree Care Operations. 2.2 Planting Layout, Massing and Plant Selection.1 Consider the limits and frequencies of institutional maintenance practices at UBC, and design accordingly for efficiency, servicing accessibility, low maintenance, weed control, pest, disease and drought tolerance. .1 Regardless of whether irrigation will be installed on site, the .
