secure boot and image authentication - qualcomm...attestation certificates in this model and is...
TRANSCRIPT
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.
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