Secure Boot and Image AuthenticationTechnical Overview

Ryan P NakamotoStaff Engineer, Product SecurityQualcomm Technologies, Inc.October 2016

2

Qualcomm Technologies Inc.

Qualcomm Snapdragon is a product of Qualcomm Technologies, Inc.

Qualcomm and Snapdragon are trademarks of Qualcomm Incorporated, registered in the United States and other countries.

Other products and brand names may be trademarks or registered trademarks of their respective owners.

Qualcomm Technologies, Inc.

5775 Morehouse Drive

San Diego, CA 92121

U.S.A.

©2016 Qualcomm Technologies, Inc.

All Rights Reserved.

Disclaimer

3

Contents

1 Overview 4

2 Signed Image Format 5

3 Image Parsing and Loading Process 6

4 CertificatesChainandFormat 7

5 Signatures 12

6 Summary 14

4

Securebootisdefinedasabootsequenceinwhicheachsoftwareimagetobeexecutedisauthenticatedbysoftwarethatwas

previouslyverified.Thissequenceisdesignedtopreventunauthorizedormodifiedcodefrombeingrun.Ourchainoftrustisbuilt

accordingtothisdefinition,startingwiththefirstpieceofimmutablesoftwaretoberunoutofread-only-memory(ROM).Thisfirst

ROMbootloadercryptographicallyverifiesthesignatureofthenextbootloaderinthechain,thenthatbootloadercryptographically

verifiesthesignatureofthenextsoftwareimageorimages,andsoon.

OntheapplicationsprocessorthefirstpieceofROM-basedsoftwarementionedabove,whichwecallthePrimaryBootLoader

(PBL),typicallyloadsandauthenticatesaSecondaryBootLoader(SBL)oreXtensibleBootLoader(XBL)asthenextimageto

berun.Thisimagethenloadsandauthenticatesafeature-richapplicationsbootloadersuchasLittleKernel(LK)ortheUnified

ExtensibleFirmwareInterface(UEFI)thatisspecifictotheOperatingSystem(OS)thatitwillsubsequentlyload.Inmodern

QualcommTechnologiesproducts,thesesoftwareimagesareallstandardExecutableandLinkableFormat(ELF)images.

Likemostdigitallysignedsoftware,theseimagesignaturesincludeacertificatechain.The“Attestationcertificate”referstothe

lowestlevelcertificateauthorizingthesignatureofthesoftwareimage.Thiscertificateissignedbythe“AttestationCAcertificate”

whichisinturnsignedbythe“RootCAcertificate”.TheRootCAcertificateisvalidatedbycomputingitshashandcomparingto

avaluestoredeitherineFuseorinROM(eFuseisasetofhardwareembeddedone-timeprogrammablebitsthatonce“blown”

cannotbereverted).ThisstoredRootCAhashvalueisprovisionedtothedevicebytheOEM,givingthemfullcontrolofthe

device’scryptographicrootoftrust.ThecertificatechainhierarchyisshowninFigure3andlaterdescribedinmoredetail.Two-

certificatechainsarealsosupported,whereintheAttestationcertificateissigneddirectlybytheRootCAcertificate.

Unlike other signed software images, the signature for Qualcomm Technologies signed images is only computed over a single

segment in the image and not the entire image. The segment containing the signature is called the hash segment. This hash

segment is a collection of the hash values of the other ELF segments that are included in the image. In other words we sign the

collectionofELFsegmenthashes,ratherthansigningtheentireELFimage.Thisrepresentationisdesignedtorelaxmemorysize

requirementsandincreasesflexibilityduringloading.TheAttestationcertificateusedtoverifythesignatureonthishashsegment

alsoincludesadditionalfieldsthatcanbindrestrictionstothesignature(preventing“rollingback”toolderversionsofthesoftware

image,restrictingthesignaturetoaparticulartypeofsoftwareimage,aparticularmodelofhardware,aparticularOEM,etc.).

The following sections of this document discuss the format of our signed ELF images, the process of loading and authenticating

thoseimages,certificatecontents,andsignaturealgorithmsingreaterdetail.

1 Overview

5

Aspreviouslymentioned,thesoftwareimageisanELFfileandcontainsthestandardELFandprogramheaders.Both32-bitand

64-bitELFclassesaresupported.SeeFigure1foranexample32-bitELFimage.

2 Signed Image Format

The hash table segment, or simply hash segment, typically follows the ELF and Program headers in the image. It contains its own

40-byteheaderwhichspecifiesthesizeoftheentirehashsegment,thesizeofthetableofhashes,thesizeoftheattestation

signature,andthesizeofthecertificatechain(allinbytes).ThishashtablecontainstheSHA-256digestofeachsegmentin

the ELF image, as well as a digest for the ELF and Program headers. It is important to authenticate these headers since they

containimportantinformation(addresses,executionentrypoint,etc.).Thesignaturefortheimageiscomputedoverthistableof

digestsandappendedtoit,alongwiththecertificatechain,toformthehashsegment.Theentryinthehashtablecorresponding

tothehashsegmentitselfisempty,astheentirehashsegmentisauthenticatedduringsignatureverification.Thesignatureis

accompaniedbyacertificatechain,asseeninFigure2.

Figure1:ELFandPROGRAMheadersina32-bitELF

6

3 Image Parsing and Loading Process

1ELFforARMarchitecture–http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf

Figure2:HashTableSegmentandSignature

Elf Segment 1

Hash Table Segment

Program Headers

Elf Header

Hash(Elf Hdr || Prog. Hdr)<Empty>Hash(Elf Segment 1)Hash(Elf Segment 2)Hash(Elf Segment 3)

Signature

Cert Chain

Hash Table Header

Elf Segment 2

Elf Segment 3

Attestation Cert

Root Key Hash

CA CertVerify Signature

Root Cert

validate

Verify Signature

Verify Signature

Whenanimageistobeauthenticatedandexecuted,itmustfirstbeloadedfrompersistentstorageintointernalmemory.Internal

memoryisgenerallyprotectedandtrustedbutonlyavailablewhenthedeviceispowered.Externalflashstorageandexternal

RAMareaccessiblebyotherentitiesandthusconsidereduntrusted.Inordertoensuretheimagehasnotbeenmodifiedor

tamperedwith,itmustbeauthenticatedwithinthetrustboundaryininternalmemorybeforebeingexecuted.

FirsttheELFheaderisloadedfromstorage,parsed,andvalidated.TheELFheaderspecifiesanumberofthings,including

programandsectionheadersizesandoffsets,aswellasthevirtualaddressoftheimage’sentry-point.NexttheProgramheaders

areloaded,parsed,andvalidated.SeetheELFspecificationforARMarchitectureformoredetailonELF1.

One and only one of the program headers must represent a hash segment, which is indicated by a segment type value in the

program header’s p_fl agsfield.Whenthathashsegmentisfound,itisloadedtointernalmemoryforauthentication.Thehash

segmentisthenauthenticatedbyverifyingitssignatureandaccompanyingcertificatechain(furtherdetailedinthefollowing

sections).TheELFheadersandprogramheadersarehashedandcomparedtotheircorrespondingentryintheauthenticated

hashtablesegment.Eachnon-pagedLOADsegmentintheELFfileisthenloadedfromstorageintointernalmemoryand

hashed. Each segment’s calculated hash is compared to its corresponding entry in the authenticated hash table in the same order

asitappearsintheprogramheader(segmentsthereforecannotbereordered).Sincethehashsegmentisverified,comparing

computedhashesofsegmentsandtheheadersprovidesequivalentsecuritytoverifyingasignatureoftheentireimagewhilealso

allowingforloadingandauthenticatingonaper-segmentbasis.

7

4 CertificatesChainandFormat

2Inatwo-certificatechain,theAttestationcertificateappearsfirstandissigneddirectlybyaself-signedRootcertificatethatfollows.

Whenheadersorsegmentsareloadedfromexternalstorage,theirdestinationaddressandsizeinmemoryisverifiedtobefully

containedinawhitelisttoconfirmthattheyarestrictlyconfinedtothememoryspaceallottedforthem.Thisisdesignedto

preventdatafrombeingwrittentounauthorizedmemoryaddresses,addresseswhereotherdataalreadyresides,orfromspilling

overintoanotherregion.Whencalculatingtheseoffsetsandsizes,thearithmeticischeckedtoensuretheresultdoesnot

overflow(i.e.wraparoundpastzero).Thesechecksarealsoperformedontheotherheaders,thecertificates,andotheritems

whereoffsetsandsizesarecalculated.

Thecertificatechaincanconsistoftwoorthreecertificates,allfollowingtheITU-TX.509v3format.Thecertificatechain

includesanAttestationcertificate,(optionally)anAttestationCAcertificate2,andaRootCAcertificate.Eachissignedbythenext

certificateinthechain,asshowninFigure3.TheSHA-256hashdigestoftheRootCAcertificatemustmatchthevaluestoredin

eFuse or stored in ROM in order to anchor the chain of trust.

Atwo-certificatechainisdesignedtoreducetheon-deviceverificationtimeandcertificatechainsizeofeachimagebyone

certificate.Inexchange,theserver-sidesignerhaslessflexibilityinauthorizingentitiestogenerateAttestationcertificates(thejob

oftheAttestationCA).Thisserver-sidesigneralsolosestheabilitytorevokethatauthorizationsincetheRootCAdirectlysigns

AttestationcertificatesinthismodelandisanchoredtoeFuseson-device.

Figure3:CertificateChainStructure

TheRootCAandAttestationCAcertificatesaretypicalX.509certificatescontainingthesamefieldsasthoseyoumightfind

securingawebbrowsingsession.TheAttestationcertificatehowever,willincludeadditionaldetailsinitsOrgUnit(OU)fields.All

certificatesarefullyconformanttoX.509.Profiles1-3belowdisplaycertificatefieldstakenfromthecertificatechainofasigned

Qualcomm®Snapdragon™820processoreXtensibleBootLoader(XBL)image.

8

Profile1:RootCertificateProfile

9

Profile2:AttestationCACertificateProfile

ThecalculatedSHA-256digestoftheRootCAcertificateseeninProfile1wouldneedtomatchthevalueinthedevice’seFuseor

ROMinorderforthisRootCAcertificatetobevalidonthatdevice.

TheBasicConstraintsindicatethatthiscertificatecansignothercertificates(CA=TRUE).WeseethattheAttestationCAcertificate

canalsosigncertificates,butonlyaleafcertificateliketheAttestationcertificate(CA=TRUE, pathLen=0).Bothcertificates’Key

Usageindicatetheyareauthorizedforcertificatesignatures.TheSubjectKeyIdentifierandAuthorityKeyIdentifierfieldsindicate

thattheRootCAistheauthorityfortheAttestationCA(andtheAttestationCAistheauthorityfortheAttestationcertificate

below).Thesetwofieldsareincludedmostlyfortrackingratherthanforsecuritypurposes.

10

Profile3:AttestationCertificateProfile

TheBasicConstraintsoftheAttestationcertificateindicatethatthiscertificatecannotsignothercertificates(CA=FALSE)butthat

KeyUsageindicatesitisauthorizedfordigitalsignatures(signingthesoftwareimage).WhilethesameRootCAandAttestation

CAmaybeusedformultipleimagesonmultipledevices,anewAttestationcertificateisgeneratedforeachsignedimageinstance.

TheAttestationcertificatecontainsOUfieldswhichmayprovideinformationorrestrictionsonthatsignedimageinstance.The

valuesfoundinOUfieldsmaythenbevalidatedagainstthosereadfromeFuseorexplicitlyexpectedbytheverifyingsoftware.We

discussthecommonOUfieldsbelow.

11

QualcommTechnologiesOUFields

TheOUfieldsaredesignedtocryptographicallybindvariousattributestothesignatureandtoprovideinformationaboutthe

image and/or signature.

01 SW_IDThesoftwareIDbindsthesignaturetoaparticularversionofaparticularsoftwareimage.This64-bitvalueisaconcatenationof

those two values:

01 SW_ID VERSION (32-bit) || IMAGE_ID (32-bit)

Thevalue“0x0000000000000000”indicatesversion0ofIMAGE_ID0(XBL).IfeFusevaluesindicatedthatthecurrentversionwas

“1”,thenthisimagewouldfailverification.Versionenforcementisdoneinordertopreventloadinganolder,perhapsvulnerable,

versionoftheimagethathasavalidsignatureattached.TheIMAGE_IDcheckisenforcedtoconfirmthatweareloadingand

verifyingthesoftwareimagethatisexpectedtoexecutenext–inthiscase,XBLVersion0.

02 HW_IDThehardwareIDbindsthesignaturetoaparticulardevicefamily,model,andOEM.Intheexampleshown,theHW_IDis

constructed as follows:

02 HW_ID MSM_ID (32-bit) || OEM_ID (16-bit) || MODEL_ID (16-bit)

Thevalue“0x009470E12A703DB9”indicatesthatthisimagewassignedforadevicewithMSM_ID0x009470E1,OEM_ID0x2A70, and

MODEL_ID0x3DB9.TheMSM_IDisauniqueidentifierchosenbyQualcommTechnologiestodesignateaspecificchip-typewithin

agivenchip-family.ThefieldscontainedinHW_IDmustmatchthoseprovisionedineFuseforthesignaturetobevalid.Therefore

thissignaturewouldbeinvalidonanyotherchipmodelorchip-type.Itwouldalsobeinvalidonamatchingdevicemodeland

chip-typewithadifferingOEM_IDvalueineFuse;alegitimatesignaturecreatedbyOEM“A”willnotbevalidonanyotherOEM’s

device–evenfortheexactsamesoftwareimageversionandtypeonadeviceusingtheexactsamemodelandchip-type.

03DEBUGTheDebugOUfieldindicateswhetherdebugcapabilityshouldbedisabledornot.Inthecertificateabove,thedebugvalueisset

toDISABLED(“0x0000000000000002”).

04 OEM_IDOU04isaneasy-to-readcopyoftheOEM_IDfromtheHW_IDfield,andisforinformationonly.ThevalueofOEM_IDisenforcedin

theHW_IDvalidationdescribedabove.

05 SW_SIZEThisOUfieldindicatesthesizeofthedatabeingsigned(notthesizeofthesoftwareimage).FromFigure2weseethisincludes

theHashTableHeader(40-bytes)andtheHashTableEntries(32-bytesperentry).Thevalueof0x248 indicates that there are 17

segmentsinthisimage.ThisOUfieldisforinformationonly.

06 MODEL_IDOU06isaneasy-to-readcopyoftheMODEL_IDfromtheHW_IDfield,andisforinformationonly.ThevalueofMODEL_IDis

enforcedintheHW_IDvalidationdescribedabove.

12

3DrawnfromtextspecificationinPKCS#1v2.1:RSACryptographyStandard

07 SHA256 / SHA1ThisOUfieldindicateswhichhashalgorithmisusedtocalculatethehashduringsignatureverification.SHA-256andSHA-1are

thecurrentoptions.TheexamplespecifiesSHA-256(“0001”)asthehashalgorithm.

5 Signatures

SignatureAlgorithmsTheRSASSA-PKCS#1v1.5signatureschemeissupportedwithSHA-256orSHA-1astheunderlyinghashalgorithm.Newer

chipsetsalsosupportRSASSA-PSSwithSHA-256astheunderlyinghashalgorithm.Apublicexponentof3or65,537issupported

forRSASSA-PKCS#1v1.5,whileonlypublicexponent65,537issupportedforRSASSA-PSS.StandardECDSAoverP-384with

SHA-384astheunderlyinghashalgorithmisalsosupportedonalimitednumberofchipsets.

CertificateSignaturesThecertificatesignaturesareallfullyX.509compliant.Thecertificatechaincanbecreated,parsed,andverifiedbyanopen

sourceX.509complianttool(suchasOpenSSL).ThedetailedspecificationforboththeRSASSA-PKCS#1v1.5andRSASSA-PSS

signatureschemescanbefoundin“PKCS #1 v2.1: RSA Cryptography Standard”,publishedbyRSALaboratories.

ImageHashSegmentSignatureRSASSA-PKCS#1 v1.5

Afterthecertificatechainhasbeenverified,thesignatureonthesoftwareimage’shashsegmentisthenverified.(Thehash

segmentsignatureistheblue“Signature”appendedtothegreen“Source”boxshowninFigure3.)Theattestationcertificate

indicateswhichsignaturealgorithmisusedtoverifytheimagesignature.ThestandardRSASSA-PKCS#1v1.5signaturescheme

message-encoding(sometimessimplyreferredtoas“padding”)isshowninFigure5.The“Hash”bubbletherereferstoastandard

SHA-256orSHA-1hashfunction,and“T”includesASN.1DigestInfoconcatenatedwiththeresultof“Hash”.

M HASH

H(hLen)

Hash Algorithm ID (DER)(0x30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20)

HT =

T00PS0x(FF) 8+ Octets0100EM =

Figure5:RSASSA-PKCS1v1.5StandardEncoding3

13

QualcommTechnologieshashsegmentsignaturesoftypeRSASSA-PKCS#1v1.5varyslightlyfromthestandardinthemessage

encoding, and in the hash construction. The hash computation and encoded message padding are shown pictographically in

Figure6.Thevalues“ipad”and“opad”aretakenfromtheHMACspecification.

H0

HASH

HM00PS0x(FF) 8+ Octets0100EM =

SW_ID ipad

H1HW_ID opad

HASH

M

HASH

H

Figure6:QualcommTechnologiesRSASSA-PKCS1v1.5ImageSignatureEncoding

OurhashsegmentsignatureexcludestheDigestInfofromtheencodedmessage(EM),andusesanHMAC-likehashkeyedwith

SW_ID,HW_IDratherthanasinglekey“K”.Thisisdesignedtoprovideastrongbindingofthetwomostimportantidentifiers

(SW_IDandHW_ID)totheimagehash(HM)usedinsigning,ratherthanbeingrelegatedtosoftwarechecks.Thehashalgorithm

ID from Figure 5 is not needed here since OU 07 is used to specify the hash algorithm.

RSASSA-PSS

ThehashsegmentsignatureformatforPSSisstandards-compliant,asarethecertificatesignatures.OnlySHA-256issupported

for“Hash”and“MGF”inthePSSsignaturescheme.Forreference,themessage-encodingschemeforPSSisgiveninFigure7.

14

4FromPKCS#1v2.1:RSACryptographyStandard

Figure7:RSASSA-PSSEncoding4

6 Summary

Software images are loaded from untrusted storage to internal trusted memory and parsed. The loading and parsing phase

includesaddressandsizevalidationagainstwhitelistedaddressrangesandintegeroverflowcheckswhencalculatingoffsetsand

end addresses. First the image’s ELF and Program headers are loaded and parsed, then the hash segment is loaded and parsed.

Thehashsegmentissignedwithatwoorthreecertificatechain.Eachcertificate’ssignatureisverifiedwiththepublickey

authorizedbythecertificateaboveit.TheAttestationcertificateisverifiedbytheAttestationCAcertificateinthethree-certificate

chain(butisverifiedbytheRootCAcertificateinthetwo-certificatechain).Ifpresent,theAttestationCAcertificateisverifiedby

theRootCAcertificate.TheRootCAcertificateisvalidatedbycomparingitshashtotheOEM-provisionedvalueineFuseorin

ROM.Thesoftwareimage’shashsegmentsignatureisverifiedbythepublickeyauthorizedbytheAttestationcertificate.This

hashsegmentsignatureverificationincludesenforcementofbindingsbetweenQualcommTechnologiesOUfieldspresentinthe

Attestationcertificateandthecorrespondingvalueson-device.AnewAttestationcertificateisgeneratedeachtimeanimageis

signed,makingthemuniquepersoftwareimageandinstance.

15

ThecertificatechainsignaturealgorithmssupportstandardRSASSA-PKCS#1v1.5withSHA-1orSHA-256andRSASSA-PSSwith

SHA-256.Theimagehashsegmentsignaturesupportsastandard-variantRSAPKCS#1v1.5withSHA-1orSHA-256andstandard

RSASSA-PSSwithSHA-256.ECDSAoverP-384withSHA-384issupportedforbothcertificatechainsignaturesandimagehash

segment signatures on a limited number of chipsets.

Afterthecertificatechainandimagesignatureshavebeenverified,eachNON-PAGEDLOADsegmentintheELFimageishashed

andcomparedagainstitshashsegmententry.Ifthecomparisonfails,oranentrydoesnotexistforthatsegment,thenthe

verificationsequencefails.Otherwise,allloadedsegmentsofthesoftwareimagehavepassedverification,leadingbackthrough

the chain of trust to the root of trust.

Executionisnowtransferredtotheentrypointoftheimagethathasjustbeensuccessfullyverified.Whenthenextsoftware

imageistobeloaded,authenticated,andexecuted,thesameprocessisrepeated.

Figure 8: The Chain of Trust

Root CA Hash [eFuse/ROM]

Root CA Cert. Attestation CA Cert.

Attestation Cert.

Hash Segment& Headers

LOADSegments

16