Visit to download the full and correct content document: https://textbookfull.com/product/fundamentals-of-ip-and-soc-security-design-verificatio n-and-debug-1st-edition-swarup-bhunia/
More products digital (pdf, epub, mobi) instant download maybe you interests ...
IP Cores Design from Specifications to Production: Modeling, Verification, Optimization, and Protection 1st Edition Khaled Salah Mohamed (Auth.)
https://textbookfull.com/product/ip-cores-design-fromspecifications-to-production-modeling-verification-optimizationand-protection-1st-edition-khaled-salah-mohamed-auth/
18th edition IET wiring regulations Design and verification of electrical installations Scaddan
https://textbookfull.com/product/18th-edition-iet-wiringregulations-design-and-verification-of-electrical-installationsscaddan/
Embedded System Design Introduction to SoC System Architecture 1st Edition Mohit Arora
https://textbookfull.com/product/embedded-system-designintroduction-to-soc-system-architecture-1st-edition-mohit-arora/
Fundamentals of Computer Architecture and Design Ahmet
Bindal
https://textbookfull.com/product/fundamentals-of-computerarchitecture-and-design-ahmet-bindal/
Fundamentals of Microwave and RF Design Michael Steer https://textbookfull.com/product/fundamentals-of-microwave-andrf-design-michael-steer/
Geospatial Analysis of Public Health Gouri Sankar
Bhunia
https://textbookfull.com/product/geospatial-analysis-of-publichealth-gouri-sankar-bhunia/
Security Operations Center Guidebook A Practical Guide for a Successful SOC Gregory Jarpey
https://textbookfull.com/product/security-operations-centerguidebook-a-practical-guide-for-a-successful-soc-gregory-jarpey/
The Fundamentals of Event Design 1st Edition Antchak https://textbookfull.com/product/the-fundamentals-of-eventdesign-1st-edition-antchak/
Foundations of Hardware IP Protection 1st Edition
Lilian Bossuet
https://textbookfull.com/product/foundations-of-hardware-ipprotection-1st-edition-lilian-bossuet/
Swarup Bhunia · Sandip Ray
Susmita Sur-Kolay Editors
Fundamentals of IP and SoC Security Design, Verification, and Debug
FundamentalsofIPandSoCSecurity SwarupBhunia ⋅ SandipRay SusmitaSur-Kolay Editors
SwarupBhunia DepartmentofElectricalandComputer Engineering
UniversityofFlorida
Gainesville,FL USA
SandipRay NXPSemiconductors Austin,TX USA
SusmitaSur-Kolay
AdvancedComputingandMicroelectronics Unit
IndianStatisticalInstitute Kolkata India
ISBN978-3-319-50055-3ISBN978-3-319-50057-7(eBook) DOI10.1007/978-3-319-50057-7
LibraryofCongressControlNumber:2016958715
©SpringerInternationalPublishingAG2017
Thisworkissubjecttocopyright.AllrightsarereservedbythePublisher,whetherthewholeorpart ofthematerialisconcerned,specificallytherightsoftranslation,reprinting,reuseofillustrations, recitation,broadcasting,reproductiononmicrofilmsorinanyotherphysicalway,andtransmission orinformationstorageandretrieval,electronicadaptation,computersoftware,orbysimilarordissimilar methodologynowknownorhereafterdeveloped.
Theuseofgeneraldescriptivenames,registerednames,trademarks,servicemarks,etc.inthis publicationdoesnotimply,evenintheabsenceofaspecificstatement,thatsuchnamesareexemptfrom therelevantprotectivelawsandregulationsandthereforefreeforgeneraluse.
Thepublisher,theauthorsandtheeditorsaresafetoassumethattheadviceandinformationinthis bookarebelievedtobetrueandaccurateatthedateofpublication.Neitherthepublishernorthe authorsortheeditorsgiveawarranty,expressorimplied,withrespecttothematerialcontainedhereinor foranyerrorsoromissionsthatmayhavebeenmade.
Printedonacid-freepaper
ThisSpringerimprintispublishedbySpringerNature TheregisteredcompanyisSpringerInternationalPublishingAG Theregisteredcompanyaddressis:Gewerbestrasse11,6330Cham,Switzerland
1TheLandscapeofSoCandIPSecurity
SandipRay,SusmitaSur-KolayandSwarupBhunia
2SecurityValidationinModernSoCDesigns
SandipRay,SwarupBhuniaandPrabhatMishra
3SoCSecurityandDebug ..................................
WenChen,JayantaBhadraandLi-C.Wang
4IPTrust:TheProblemandDesign/Validation-Based Solution ................................................
RajGautamDutta,XiaolongGuoandYierJin
5SecurityofCryptoIPCore:IssuesandCountermeasures .......
DebapriyaBasuRoyandDebdeepMukhopadhyay 6PUF-BasedAuthentication
JimPlusquellic
7FPGA-BasedIPandSoCSecurity
DebasriSahaandSusmitaSur-Kolay
8PhysicalUnclonableFunctionsandIntellectualProperty ProtectionTechniques ....................................
RameshKarri,OzgurSinanogluandJeyavijayanRajendran
9ASystematicApproachtoFaultAttackResistantDesign
NahidFarhadyGalathy,BilgidayYuceandPatrickSchaumont
10HardwareTrojanAttacksandCountermeasures ...............
HassanSalmani
11In-placeLogicObfuscationforEmergingNonvolatileFPGAs 277 Yi-ChungChen,YandanWang,WeiZhang,YiranChen andHai(Helen)Li
12SecurityStandardsforEmbeddedDevicesandSystems .........
VenkateswarKowkutlaandSrivathsRavi
13SoCSecurity:SummaryandFutureDirections ................ 313 SwarupBhunia,SandipRayandSusmitaSur-Kolay
Chapter1 TheLandscapeofSoCandIPSecurity SandipRay,SusmitaSur-KolayandSwarupBhunia
1.1Introduction
Ithasbeenalmostadecadesincethenumberofsmart,connectedcomputingdevices hasexceededthehumanpopulation,usheringintheregimeoftheInternetof things[1].Today,weliveinanenvironmentcontainingtensofbillionsofcomputing devicesofwidevarietyandformfactors,performingarangeofapplicationsoften includingsomeofourmostprivateandintimatedata.Thesedevicesincludesmartphones,tablets,consumeritems(e.g.,refrigerators,lightbulbs,andthermostats), wearables,etc.Thetrendistowardthisproliferationtoincreaseexponentiallyinthe comingdecades,withestimatesgoingtotrillionsofdevicesasearlyasby2030, signifyingthefastestgrowthbyalargemeasureacrossanyindustrialsectorinthe historyofthehumancivilization.
Securityandtrustworthinessofcomputingsystemsconstituteacriticalandgating factortotherealizationofthisnewregime.Withcomputingdevicesbeingemployed foralargenumberofhighlypersonalizedactivities(e.g.,shopping,banking,fitnesstracking,providingdrivingdirections,etc.),thesedeviceshaveaccesstoalarge amountofsensitive,personalinformationwhichmustbeprotectedfromunauthorizedormaliciousaccess.Ontheotherhand,communicationofthisinformationto otherpeerdevices,gateways,anddatacentersisinfactcrucialtoprovidingthekind ofadaptive,“smart”behaviorthattheuserexpectsfromthedevice.Forexample,
S.Ray(✉)
StrategicCADLabs,IntelCorporation,Hillsboro,OR97124,USA e-mail:sandip.ray@intel.com
S.Sur-Kolay
AdvancedComputingandMicroelectronicsUnit,IndianStatisticalInstitute, Kolkata700108,India e-mail:ssk@isical.ernet.in
S.Bhunia
DepartmentofECE,UniversityofFlorida,Gainesville,FL32611,USA e-mail:swarup@ece.ufl.edu
©SpringerInternationalPublishingAG2017
S.Bhuniaetal.(eds.), FundamentalsofIPandSoCSecurity, DOI10.1007/978-3-319-50057-7_1
asmartfitnesstrackermustdetectfromitssensorydata(e.g.,pulserate,location, speed,etc.)thekindofactivitybeingperformed,theterrainonwhichtheactivityis performed,andeventhemotivationfortheactivityinordertoprovideanticipated feedbackandresponsetotheuser;thisrequiresahighdegreeofdataprocessingand analysismuchofwhichisperformedbydatacentersorevengatewayswithhigher computingpowerthanthetrackerdeviceitself.Thecommunicationandprocessingofone’sintimatepersonalinformationbythenetworkandthecloudexposes theriskthatitmaybecompromisedbysomemaliciousagentalongtheway.In additiontopersonalizedinformation,computingdevicescontainhighlyconfidential collateralfromarchitecture,design,andmanufacturing,suchascryptographicand digitalrightsmanagement(DRM)keys,programmablefuses,on-chipdebuginstrumentation,defeaturebits,etc.Maliciousorunauthorizedaccesstosecureassetsin acomputingdevicecanresultinidentitythefts,leakageofcompanytradesecrets, evenlossofhumanlife.Consequently,acrucialcomponentofamoderncomputing systemarchitectureincludesauthenticationmechanismstoprotecttheseassets.
1.2SoCDesignSupplyChainandSecurityAssets Mostcomputingsystemsaredevelopedtodayusingthesystem-on-chip(SoC)design architecture.AnSoCdesignisarchitectedbyacompositionofanumberofpredesignedhardwareandsoftwareblocks,oftenreferredtoas designintellectualproperties ordesignIPs(IPsforshort).Figure 1.1 showsasimpletoySoCdesign,includingsome“obvious”IPs,e.g.,CPU,memorycontroller,DRAM,variouscontrollers forperipherals,etc.Ingeneral,anIPcanrefertoanydesignunitthatcanbeviewed asastandalonesub-componentofacompletesystem.AnSoCdesignarchitecture thenentailsconnectingtheseIPstogethertoimplementtheoverallsystemfunctionality.ToachievethisconnectionamongIPs,anSoCdesignincludesanetwork-onchip(NoC)thatprovidesastandardizedmessageinfrastructurefortheIPstocoordinateandcooperatetodefinethecompletesystemfunctionality.Inindustrialpractice today,anSoCdesignisrealizedbyprocuringmanythird-partyIPs.TheseIPsare thenintegratedandconnectedbytheSoCdesignintegrationhousewhichisresponsibleforthefinalsystemdesign.Thedesignincludesbothhardwarecomponents (writteninahardwaredescriptionlanguagesuchasVerilogofVHDLlanguage)as wellassoftwareandfirmwarecomponents.Thehardwaredesignissenttoafoundry orfabricationhousetocreatethesiliconimplementation.Thefabricateddesignis transferredtoplatformdevelopersorOriginalEquipmentManufacturers(OEMs), whocreatecomputingplatformssuchasasmartphone,tablet,orwearabledevices, whichareshippedtotheendcustomer.
ThedescriptionabovealreadypointstoakeyaspectofcomplexityinSoCdesign fabrication,e.g.,acomplexsupplychainandstakeholders.Thisincludesvarious IPproviders,theSoCintegrationhouse,foundry,andtheOEMs.Furthermore,with increasingglobalization,thissupplychainistypicallylongandgloballydistributed.
Chapter 2 discussessomeramificationsofthisinfrastructure,e.g.,thepossibility
Fig.1.1 ArepresentativeSoCdesign.SoCdesignsarecreatedbyputtingtogetherintellectual property(IP)blocksofwell-definedfunctionality
ofanycomponentofthesupplychainincorporatingmaliciousorinadvertentvulnerabilityintothedesignorthemanufacturingprocess.Maliciousactivitiescan includeinsertionofspecificdesignalterationsorTrojansbyIPproviders,leaking ofasecurityassetbytheSoCintegrationhouse,overproductionorcounterfeitingby amaliciousfoundry,andevenoverlookedorapparentlybenigndesignerrorsorfeaturesthatcanbeexploitedon-field.Securityarchitecturesandassurancetechniques andmethodologiesmustberobustenoughtoaddresschallengesarisingfromthis plethoraofsources,arisingfromdifferentpointsofthesystemdesignlifecycle.
1.3TheChallengeofDesignComplexity AseconddimensionofchallengeswiththesecureSoCdesignisinthesheercomplexity.Moderncomputingsystemsareinordinatelycomplex.NotefromFig. 1.1 thattheCPUrepresents"merely"oneofalargenumberofIPsinanSoCdesign. TheCPUinamodernSoCdesignisarguablymorecomplexthanmanyofthehighperformancemicroprocessorsofadecadeback.Multiplythiscomplexityincrease withthelargenumberofIPsinthesystem(manyofwhichincludecustommicrocontrollersofcommensuratecomplexity,inadditiontocustomhardwareandfirmware), andonegetssomesenseofthelevelofcomplexity.Addsomeothercross-designfeatures,e.g.,powermanagement,performanceoptimization,multiplevoltageislands, clockinglogic,etc.,andthecomplexityperhapsgoesbeyondimagination.Thenumberofdifferentdesignstatesthatsuchasystemcanreachexceedsbyalongwaythe numberofatomsintheuniverse.Itischallengingtoensurethatsuchasystemever functionsasdesiredevenundernormaloperatingconditions,muchlessinthepresenceofmillionsofadversarieslookingtoidentifyvulnerabilitiesforexploitation. Whyisthiscomplexityabottleneckforsecurityinparticular?Forstarters,secure assetsaresprinkledacrossthedesign,invariousIPsandtheircommunication infrastructure.Itisdifficulttoenvisageallthedifferentconditionsunderwhichthese assetsareaccessedandinsertappropriateprotectionandmitigationmechanismsto ensureunauthorizedaccess.Furthermore,securitycross-cutsdifferentIPsofthesystem,insomecasesbreakingtheabstractionofIPsascoherent,distinctblocksof well-definedfunctionality.ConsideranIPcommunicatingwithanotheronethrough thecommunicationfabric.SeveralIPsareinvolvedinthisprocess,includingthe sourceanddestinationIPs,theroutersinvolvedinthecommunication,etc.Ensuring thecommunicationissecurewouldrequireanunderstandingofthisoverallarchitecture,identifyingtrustedanduntrustedcomponents,analyzingtheconsequencesofa Trojaninoneoftheconstituentblocksleakinginformation,andmuchmore.Toexacerbatetheissue,designfunctionalitytodayishardlycontainedentirelyinhardware. MostmodernSoCdesignfunctionalityincludessignificantfirmwareandsoftware componentswhichareconcurrentlydesignedtogetherwithhardware(potentiallyby differentplayersacrossthesupplychain).Consequently,securitydesignandvalidationbecomeacomplexhardware/softwareco-designandco-validationproblem distributedacrossmultipleplayerswithpotentiallyuntrustedparticipants.Finally, thesecurityrequirementsthemselvesvarydependingonhowanIPoreventheSoC designisusedinaspecificproduct.Forexample,thesameIPwhenusedinawearabledevicewillhaveadifferentsecurityrequirementfromwhenitisusedasagamingsystem.Thesecurityrequirementsalsovarydependingonthestageofthelife cycleoftheproduct,e.g.,whenitiswithamanufacturer,OEM,orendcustomer.This makesithardtocompositionallydesignsecurityfeatureswithoutaglobalview.
1.4StateofSecurityDesignandValidation: ResearchandPractice Therehasbeensignificantresearchinrecentyearstoaddressthechallengesoutlined above.Therehavebeentechniquestodefinesecurityrequirements[2, 3],architecturestofacilitatesuchimplementation[4–7],testingtechnologiestodefineandemulatesecurityattacks[8],andtoolstovalidatediverseprotectionandmitigationstrategies[9–12].Therehavebeencross-cuttingresearchtoo,onunderstandingtrade-offs betweensecurityandfunctionality,energyrequirements,validation,andarchitecturalconstraints[13, 14].
Inspiteoftheseadvances,thestateoftheindustrialpracticeisstillquiteprimitive.Westilldependonsecurityarchitects,designers,andvalidatorspainstakingly mappingoutvarioussecurityrequirements,architectinganddesigningvarioustailoredandcustomizedprotectionmechanisms,andcomingupwithattackscenariosto breakthesystembywayofvalidation.Thereisaseverelackofdisciplinedmethodologyfordevelopingsecurity,inthesamescaleasthereismethodologyfordefining andrefiningarchitecturesandmicro-architecturesforsystemfunctionalityorperformance.Unsurprisingly,securityvulnerabilitiesareaboundinmodernSoCdesigns, asevidencedbythefrequencyandeaseinwhichactivitieslikeidentitytheft,DRM override,devicejailbreaking,etc.areperformed.
1.5TheBook ThisbookisanattempttobridgeacrosstheresearchandpracticeinSoCsecurity. ItisconceivedasanauthoritativereferenceonallaspectsofsecurityissuesinSoC designs.ItdiscussesresearchissuesandprogressesintopicsrangingfromsecurityrequirementsinSoCdesigns,definitionofarchitecturesanddesignchoicesto enforceandvalidatesecuritypolicies,andtrade-offsandconflictsinvolvingsecurity,functionality,anddebugrequirements,aswellasexperiencereportsfromthe trenchesindesign,implementation,andvalidationofsecurity-criticalembeddedsystems.
Inadditiontoprovidinganextensivereferencetothecurrentstate-of-the-art, thebookisanticipatedtoserveasaconduitforcommunicationbetweendifferent stakeholdersofsecurityinSoCdesigns.Securityisoneoftheuniqueareasof SoCdesigns,whichcross-cutsavarietyofconcerns,includingarchitecture,design, implementation,validation,andsoftware/hardwareinterfaces,inmanycaseswith conflictingrequirementsfromeachdomain.Withaunifiedmaterialdocumenting thevariousconcernsside-by-side,wehopethisbookwillhelpeachstakeholder betterunderstandandappreciatetheotherspointsofviewandultimatelyfosteran overallunderstandingofthetrade-offsnecessarytoachievetrulysecuresystems.
Thebookincludeseleven-chaptersfocusingondiverseaspectsofsystem-level securityinmodernSoCdesigns.Thebookisintendedforresearchers,students,
andpractitionersinterestedinunderstandingthespectrumofchallengesinarchitecture,validation,anddebugofIPandSoCsecurities.Itcanserveasamaterial foraresearchcourseonthetopic,orasasourceofadvancedresearchmaterialsina graduateclass.
Chapter 2 focusesonSoCsecurityvalidation.Validationisacriticalandhighly importantcomponentinSoCsecurity.Thischapterintroducesthedifferentsecurityactivitiesperformedatdifferentstagesofthedesignlifecycle,andthecomplex dependenciesinvolved.Itdrawsfromexamplesinindustrialpractice,identifiesthe holesincurrentstateofthepractice,anddiscussesemergentresearchinindustryand academiatoplugtheseholes.
Chapter 3 discussesinteroperabilitychallengestosecurity.Forasystemtobeusable, itisnotsufficientforittobesecurebutalsotoprovidemeaningfulfunctionality. Thetrade-offsbetweensecurityandfunctionalityisanoldone,stemmingfromthe notionofavailabilityitselfasasecurityrequirementinadditiontoconfidentiality andintegrity.Interoperabilitybetweensecurityandfunctionalityisacornerstone fordesignandvalidationofmoderncomputingsystems.Thetwistinthistaleis thatvalidationitselfintroducestrade-offsandconflictswithsecurity.Inparticular, post-siliconvalidationimposesobservabilityandcontrollabilityrequirementswhich canconflictwiththesecurityrestrictionsofthesystem.Thischapterdiscussesthe variousramificationsofthisconflict,anddiscussesthecurrentstateofthepractice initsresolution.
Chapter 4 introducesthechallengeofIPtrustvalidationandassurance.Giventhe highproliferationofthird-partyIPsthatareincludedinamodernSoCdesignas wellasthecomplexglobalsupplychainalludedtoabove,trustworthinessoftheIP isamatterofcrucialconcern.ThischapterenumeratesthechallengeswiththecurrentIPtrustassurance,discussesprotectiontechnologies,anddescribescertification methodstovalidatetrustworthinessofacquiredthird-partyIPs.
Chapter 5 discusseschallengesindevelopingtrustworthycryptographicimplementationsformodernSoCdesigns.Cryptographicprotocolsarecrucialtovariousprotectingalargenumberofsystemassets.Virtually,allSoCdesignsincludeanumber ofIPcoresimplementingsuchprotocols,whichformacriticalcomponentofthe root-of-trustforthesystem.Itisobviouslycrucialthatthecryptographicimplementationsthemselvesarerobustagainstadversarialattacks.Attacksoncryptographic implementationsincludebothattacksontheprotocolsthemselvesaswellasinferenceofimplementationbehaviorandsecuredata(e.g.,key)throughsidechannel analysis.Thischapterprovidesanoverviewoftheseattacksanddiscussescountermeasures.
Chapter 6 discussesapromisingtechnologyforsecureauthentication,namelyPhysicalunclonablefunction(PUF).PUFisoneofthekeysecurityprimitivesthatprovidessourceofrandomnessforcryptographicimplementations(amongothers)inan SoCdesign.Theideaistoexploitvariationsinthestructuralandelectricalcharacteristicsasasourceofentropyuniquetoeachindividualintegratedcircuit.PUFshave
becomeatopicofsignificantresearchoverthelastdecade,withvariousnovelPUFbasedauthenticationprotocolsemerginginrecentyears.Thischapterdiscussesthis excitingandrapidlyevolvingarea,comparesPUF-basedauthenticationwithother standardapproaches,andidentifiesseveralopenresearchproblems.
Chapter 7 discussessecuritywithIPandSoCdesignsbasedonfield-programmable gatearrays(FPGA).FPGAshavebeenthefocusofattentionbecausetheypermit dynamicreconfigurabilitywhilestillprovidingtheenergyefficiencyandperformancecompatiblewithacustomhardwareimplementationformanyapplications. Unfortunately,FPGA-basedIPimplementationsinduceanumberofsignificantsecuritychallengesoftheirown.AnFPGA-basedIPisessentiallyadesignimplementationinalow-levelhardwaredescriptionlanguage(alsoreferredtoasanFPGA bitstream)whichisloadedonagenericFPGAarchitecture.Toensureauthenticationandpreventunauthorizedaccess,thebitstreamneedstobeencrypted,andmust thereafterbedecryptedon-the-flyduringloadorupdate.However,bitstreamsare oftenupdatedonfieldandtheencryptionmaybeattackedthroughsidechannelor othermeans.IftheentireSoCisimplementedinFPGA,IPmanagementandcoordinationmaybecomeevenmorechallenging.Thischapterdiscussesthevariousfacets ofsecuritytechniquesforIPandSOCFPGA,openproblems,andareasofresearch.
Chapter 8 discussesPUFsandIPprotectiontechniques.IPprotectiontechniques aretechniquestoensurerobustnessofIPsagainstvariousthreats,includingsupply chainchallenges,Trojan,andcounterfeiting.Thechapterprovidesabroadoverview oftheuseofPUFsandIPprotectiontechniquesinmodernSoCdesigns,andvarious conflicts,cooperations,andtrade-offsinvolved.
Chapter 9 discussesSoCdesigntechniquesthatareresistanttofaultinjectionattacks. Faultinjectionattackisacomplex,powerful,andversatileapproachtosubvertSoC designprotections,particularlycryptographicimplementations.Thechapterprovidesanoverviewoffaultinjectionattacksanddescribesbroadclassofdesigntechniquestodevelopsystemsthatarerobustagainstsuchattacks.
Chapter 10 lookscloselyintooneofthecoreproblemsofSoCsecurity,e.g.,hardwareTrojans.WithincreasingglobalizationoftheSoCdesignsupplychainthere hasbeenincreasingthreatofsuchTrojans,i.e.,hardwarecircuitrythatmayperformintentionallymaliciousactivityincludingsubvertingcommunications,leaking secrets,etc.ThechapterlookscloselyatvariousfacetsofthisproblemfromIPsecurityperspective,thecountermeasurestakeninthecurrentstateofpractice,theirdeficiencies,anddirectionsforresearchinthisarea.
Chapter 11 discusseslogicobfuscationtechniques,inparticularforFPGAdesigns basedonnonvolatiletechnologies.Logicobfuscationisanimportanttechniqueto providerobustnessofanIPagainstalargeclassofadversaries.ItisparticularlycriticalforFPGA-baseddesignswhichneedtobeupdatedonfield.Thechapterproposes aschemeforloadingobfuscatedconfigurationsintononvolatilememoriestoprotect designdatafromphysicalattacks.
Chapter 12 presentsadiscussiononsecuritystandardsinembeddedSoCsusedin diverseapplications,includingautomotivesystems.Itnotesthatsecurityisacritical
considerationinthedesigncycleofeveryembeddedSoC.Butthelevelofsecurityandresultingcost–benefittrade-offdependonatargetapplication.Thischapter providesavaluableindustryperspectivetothiscriticalproblem.Itdescribestwolayersofahierarchicalsecuritymodelthatasystemdesignertypicallyusestoachieve application-specificsecurityneeds:(1)foundationlevelsecuritytargetedatbasic securityservices,and(2)securityprotocolslikeTLSorSSL.
Ithasbeenapleasureandhonorfortheeditorstoeditthismaterial,andwehope thebroadcoverageofsystem-levelsecuritychallengesprovidedherewillbridge akeygapinourunderstandingofthecurrentandemergentsecuritychallenges. WebelievethecontentofthebookwillprovideavaluablereferenceforSoCsecurityissuesandsolutionstoadiversereadershipincludingstudents,researchers,and industrypractitioners.Ofcourse,itisimpossibleforanybookonthetopictobe exhaustiveonthistopic:itistoobroad,toodetailed,andtouchestoomanyareasof computerscienceandengineering.Nevertheless,wehopethatthebookwillprovide aflavorofthenatureoftheneededandcurrentresearchinthisarea,andcross-cutting challengesacrossdifferentareasthatneedtobedonetoachievethegoaloftrustworthycomputingsystems.
References
1.Evans,D.:TheInternetofThings—HowtheNextEvolutionoftheInternetisChangingEverything.WhitePaper,CiscoInternetBusinessSolutionsGroup(IBSG)(2011)
2.Li,X.,Oberg,J.V.K.,Tiwari,M.,Rajarathinam,V.,Kastner,R.,Sherwood,T.,Hardekopf,B., Chong,F.T.:Sapper:alanguageforhardware-levelsecuritypolicyenforcement.In:InternationalConferenceonArchitecturalSupportforProgrammingLanguagesandOperatingSystems(2014)
3.Srivatanakul,J.,Clark,J.A.,Polac,F.:Effectivesecurityrequirementsanalysis:HAZOPsand usecases.In: 7thInternationalConferenceonInformationSecurity,pp.416–427(2004)
4.ARM:Buildingasecuresystemusingtrustzonetechnology.ARMLimited(2009)
5.Basak,A.,Bhunia,S.,Ray,S.:AflexiblearchitectureforsystematicimplementationofSoC securitypolicies.In:Proceedingsofthe34thInternationalConferenceonComputer-Aided Design(2015)
6.Intel:Intel® SoftwareGuardExtensionsProgrammingReference. https://software.intel.com/ sites/default/files/managed/48/88/329298-002.pdf
7.Samsung:SamsungKNOX. www.samsungknox.com
8.MicrosoftThreatModeling&AnalysisToolversion3.0(2009)
9.JasperGoldSecurityPathverificationApp. https://www.cadence.com/tools/system-designand-verification/formal-and-static-verification/jasper-gold-verification-platform/securitypath-verification-app.html
10.Bazhaniuk,O.,Loucaides,J.,Rosenbaum,L.,Tuttle,M.R.,Zimmer,V.:Excite:symbolicexecutionforBIOSsecurity.In:WorkshoponOffensiveTechnologies(2015)
11.Kannavara,R.,Havlicek,C.J.,Chen,B.,Tuttle,M.R.,Cong,K.,Ray,S.,Xie,F.:Challenges andopportunitieswithconcolictesting.In:NAECON2015(2015)
12.Takanen,A.,DeMott,J.D.,Mille,C.:Fuzzingforsoftwaresecuritytestingandqualityassurance.ArtechHouse(2008)
13.Ray,S.,Hoque,T.,Basak,A.,Bhunia,S.:Thepowerplay:trade-offsbetweenenergyand securityinIoT.In:ICCD(2016)
14.Ray,S.,Yang,J.,Basak,A.,Bhunia,S.:Correctnessandsecurityatodds:post-siliconvalidationofmodernSoCdesigns.In:Proceedingsofthe52ndAnnualDesignAutomationConference(2015)
Chapter2 SecurityValidationinModernSoCDesigns SandipRay,SwarupBhuniaandPrabhatMishra 2.1SecurityNeedsinModernSoCDesigns System-on-Chip(SoC)architecturepervadesmoderncomputingdevices,beingthe prevalentdesignapproachfordevicesinembedded,mobile,wearable,andInternetof-Things(IoT)applications.Manyofthesedeviceshaveaccesstohighlysensitiveinformationordata(oftencollectivelycalled“assets”),thatmustbeprotected againstunauthorizedormaliciousaccess.ThegoalofSoCsecurity architecture isto developmechanismstoensurethisprotection.ThegoalofSoCsecurity validation istoensurethatsuchmechanismsindeedprovidetheprotectionneeded.Clearlythe twoactivitiesarecloselyinter-relatedintypicalSoCsecurityassurancemethodologies.Thischapterisaboutthesecurityvalidationcomponent,butwetouchupon architecturalissuesasnecessary.
Tomotivatethecriticalroleofsecurityvalidationactivities,itisnecessaryto clarify(1)whatkindofassetsisbeingprotected,and(2)whatkindofattacksweare protectingagainst.Onecangetsomeflavorofthekind(anddiversity)ofassetsby lookingatthekindofactivitiesweperformonatypicalmobilesystem.Figure 2.1 tabulatessomeobviousenduserusagesofastandardsmartphoneandthekindofend userinformationaccessedduringtheseusages.Notethatitincludessuchintimate informationasoursleeppattern,healthinformation,location,andfinances.Inadditiontoprivateenduserinformation,thereareotherassetsinasmartphonethatmay havebeenputbythemanufacturersandOEMs,which they donotwanttobeleaked
S.Ray(✉)
StrategicCADLabs,IntelCorporation,Hillsboro,OR97124,USA
e-mail:sandip.ray@intel.com
S.Bhunia ⋅ P.Mishra DepartmentofECE,UniversityofFlorida,Gainesville,FL32611,USA
e-mail:swarup@ece.ufl.edu
P.Mishra
e-mail:prabhat@cise.ufl.edu
©SpringerInternationalPublishingAG2017
S.Bhuniaetal.(eds.), FundamentalsofIPandSoCSecurity, DOI10.1007/978-3-319-50057-7_2
Usages Assets Exposed
Browsing Browsing history
Fitness tracking Health information,sleep pattern
GPS Location
Phone call Contacts
Banking,Stock trading Finances
Fig.2.1 Sometypicalsmartphoneapplicationsandcorrespondingprivateenduserinformation
Fig.2.2 SomepotentialattacksonamodernSoCdesign. a Potentialattackareasforasmartphone afterproductionanddeployment. b Potentialthreatsfromuntrustedsupplychainduringthedesign lifecycleofanSoCdesign
outtounauthorizedsources.ThisincludescryptographicandDRMkeys,premium contentlocks,firmwareexecutionflows,debugmodes,etc.Notethatthenotionof “unauthorizedsource”changesbasedonwhatassetwearetalkingabout:enduser maybeanunauthorizedsourceforDRMkeyswhilemanufacturer/OEMmaybean unauthorizedsourceforenduserprivateinformation.
Inadditiontocriticalityoftheassetsinvolved,anotherfactorthatmakesSoC securitybothcriticalandchallengingisthehighdiversityofattackspossible.
Figure 2.2 providesaflavorofpotentialattacksonamodernSoCdesign.Ofparticularconcernarethefollowingtwoobservations:
∙ Becauseoftheuntrustednatureofthesupplychain,therearesecuritythreatsat moststagesofthedesigndevelopment,evenbeforedeploymentandproduction.
∙ AdeployedSoCdesigninsideacomputingdevice(e.g.,smartphone)inthehand oftheenduserispronetoalargenumberofpotentialattackerentrypoints,includingapplications,software,andnetwork,browser,andsensors.Securityassurance mustpermitprotectionagainstthislargeattacksurface.
Wediscusssecurityvalidationforthecontinuumofattacksfromdesigntodeployment.Giventhattheattacksarediverse,protectionmechanismsarealsovaried,and
eachinducesasignificantlydifferentvalidationchallenge.However,validation technology isstillquitelimited.Formostofthesecurityrequirements,westillverymuch dependontheperspicuity,talent,andexperienceofthehumanvalidatorstoidentify potentialvulnerabilities.
2.2SupplyChainSecurityThreats ThelifecycleofaSoCfromconcepttodeploymentinvolvesnumberofsecurity threatsatallstagesinvolvingvariousparties.Figure 2.2bshowstheSoClifecycle andthesecuritythreatsthatspantheentirelifecycle.Thesethreatsareincreasing withtherapidglobalizationoftheSoCdesign,fabrication,validation,anddistributionsteps,drivenbytheglobaleconomictrend.
Thisgrowingrelianceonreusablepre-verifiedhardwareIPsduringSoCdesign, oftengatheredfromuntrustedthird-partyvendors,severelyaffectsthesecurityand trustworthinessofSoCcomputingplatforms.Statisticsshowthattheglobalmarket forthird-partysemiconductorIPsgrewbymorethan 10% toreachmorethan 2.1 billioninlate2012[1].Thedesign,fabrication,andsupplychainfortheseIPcoresis generallydistributedacrosstheglobeinvolvingUSA,Europe,andAsia.Figure 2.3 illustratesthescenarioforanexampleSoCthatincludesprocessor,memorycontrollers,security,graphics,andanalogcore.DuetogrowingcomplexityoftheIPs aswellastheSoCintegrationprocess,SoCdesignersincreasinglytendtotreatthese IPsasblackboxandrelyontheIPvendorsonthestructural/functionalintegrityof theseIPs.However,suchdesignpracticesgreatlyincreasethenumberofuntrusted componentsinaSoCdesignandmaketheoverallsystemsecurityapressingconcern.
HardwareIPsacquiredfromuntrustedthird-partyvendorscanhavediversesecurityandintegrityissues.AnadversaryinsideanIPdesignhouseinvolvedinthe IPdesignprocesscandeliberatelyinsertamaliciousimplantordesignmodificationtoincorporatehidden/undesiredfunctionality.Inaddition,sincemanyof theIPprovidersaresmallvendorsworkingunderhighlyaggressiveschedules, itisdifficulttoensureastringentIPvalidationrequirementinthisecosystem. Designfeaturesmayalsointroduceunintentionalvulnerabilities,e.g.,intentional informationleakagethroughhiddentest/debuginterfacesorside-channelsthrough power/performanceprofiles.Similarly,IPscanhaveuncharacterizedparametric behavior(e.g.,power/thermal)whichcanbeexploitedbyanattackertocauseirrecoverabledamagetoanelectronicsystem.Therearedocumentedinstancesofsuch attacks.Forexample,in2012,astudybyagroupofresearchersinCambridge revealedanundocumentedsiliconlevelbackdoorinahighlysecuremilitary-grade ProAsic3FPGAdevicefromMicroSemi(formerlyActel)[2],whichwaslater describedasavulnerabilityinducedunintentionallybyon-chipdebuginfrastructure.Inarecentreport,researchershavedemonstratedsuchanattackwhereamaliciousupgradeofafirmwaredestroystheprocessoritiscontrollingbyaffecting thepowermanagementsystem[3].ItmanifestsanewattackmodeforIPs,where
Fig.2.3 AnSoCwouldoftencontainhardwareIPblocksobtainedfromentitiesdistributedacross theglobe
firmware/softwareupdatecanmaliciouslyaffectthepower/performance/temperature profileofachiptoeitherdestroyasystemorrevealsecretinformationthroughappropriateside-channelattack,e.g.,afaultortimingattack.
TrustedanduntrustedCADtoolsposesimilartrustissuestotheSoCdesigners.Suchtoolsaredesignedtooptimizeadesignforpower,performance,andarea. Securityoptimizationisnotanoptionintoday’stools,hencesometimesduringthe optimizationnewvulnerabilitiesareintroduced[4].Roguedesignersinanuntrusted designfacility,e.g.,incaseofadesignoutsourcedtoafacilityforDesign-for-Test (DFT)orDesign-for-Debug(DFD)insertion,cancompromisetheintegrityofaSoC designthroughinsertionofstealthyhardwareTrojan.TheseTrojanscanactasbackdoororcompromisethefunctional/parametricpropertiesofaSoCinvariousways.
Finally,manySoCmanufacturerstodayarefablessandhencemustrelyupon externaluntrustedfoundriesforfabricationservice.Anuntrustedfoundrywould haveaccesstotheentireSoCdesignandthusbringsinseveralserioussecurityconcerns,whichincludereverse-engineeringandpiracyoftheentireSoCdesignorthe IPblocksaswellastamperingintheformofmaliciousdesignalterationsorTrojan attacks.DuringdistributionoffabricatedSoCsthroughatypicallylonggloballydistributedsupplychain,consistingofmultiplelayersofdistributors,wholesalers,and retailers,thethreatofcounterfeitsisagrowingone.Thesecounterfeitscanbelowqualityclones,overproducedchipsinuntrustedfoundry,orrecycledones[5].Even afterdeployment,thesystemsarevulnerabletophysicalattacks,e.g.,side-channel attackswhichtargetinformationleakage,andmagneticfieldattacksthataimatcorruptingmemorycontenttocausedenial-of-service(DoS)attacks.
2.3SecurityPolicies:RequirementsfromDesign Inadditiontosupply-chainthreats,thedesignitselfmayhaveexploitablevulnerabilities.Vulnerabilitiesinsystemdesign,infact,formsthequintessentialobjectiveof securitystudy,andhasbeenthefocusofresearchforoverthreedecades.Atahigh level,thedefinitionofsecurityrequirementforassetsinaSoCdesignfollowsthe well-known“CIA”paradigm,developedaspartofinformationsecurityresearch[6]. Inthisparadigm,accessesandupdatestosecureassetsaresubjecttothefollowing threerequirements:
∙ Confidentiality:Anassetcannotbeaccessedbyanagentunlessauthorizedtodo so.
∙ Integrity:Anassetcanbemutated(e.g.,thedatainasecurememorylocationcan bemodified)onlybyanagentauthorizedtodoso.
∙ Availability:Anassetmustbeaccessibletoanagentthatrequiressuchaccessas partofcorrectsystemfunctionality.
Ofcourse,mappingthesehigh-levelrequirementstoconstraintsonindividualassets inasystemisnontrivial.Thisisachievedbydefiningacollectionofsecuritypoliciesthatspecifywhichagentcanaccessaspecificassetandunderwhatconditions. Followingaretwoexamplesofrepresentativesecuritypolicies.Notethatwhileillustrative,theseexamplesaremadeupanddonotrepresentsecuritypolicyofaspecific companyorsystem.
Example1Duringboottime,datatransmittedbythecryptographicenginecannot beobservedbyanyIPintheSoCotherthanitsintendedtarget. Example2Aprogrammablefusecontainingasecurekeycanbeupdatedduring manufacturingbutnotafterproduction.
Example1isaninstanceofconfidentiality,whileExample2isaninstanceof integritypolicy;however,thepoliciesareatalowerlevelofabstractionsincethey areintendedtobetranslatedto“actionable”information,e.g.,architecturalordesign features.Theaboveexamples,albeithypothetical,illustrateanimportantcharacteristicofsecuritypolicies:thesameagentmayormaynotbeauthorizedaccess(or update)ofthesamesecurityassetdependingon(1)thephaseoftheexecution(i.e., bootornormal),or(2)thephaseofthedesignlifecycle(i.e.,manufacturingorproduction).Thesefactorsmakesecuritypoliciesdifficulttoimplement.Exacerbating theproblemisthefactthatthereistypicallynocentraldocumentationforsecurity policies;documentationofpoliciescanrangefrommicroarchitecturalandsystem integrationdocumentstoinformalpresentationsandconversationsamongarchitects, designers,andimplementors.Finally,theimplementationofapolicyisanexercise inconcurrency,withdifferentcomponentsofthepolicyimplementedindifferentIPs (inhardware,software,orfirmware),thatcoordinatetogethertoensureadherenceto thepolicy.
Unfortunately,securitypoliciesinamodernSoCdesignarethemselvessignificantlycomplex,anddevelopedinadhocmannerbasedoncustomerrequirements
andproductneeds.Followingaresomerepresentativepolicyclasses.Theyarenot complete,butillustratethediversityofpoliciesemployed.
AccessControl.Thisisthemostcommonclassofpolicies,andspecifieshowdifferentagentsinanSoCcanaccessanassetatdifferentpointsoftheexecution.Herean “agent”canbeahardwareorsoftwarecomponentinanyIPoftheSoC.Examples1 and2aboverepresentsuchpolicy.Furthermore,accesscontrolformsthebasisof manyotherpolicies,includinginformationflow,integrity,andsecureboot.
InformationFlow.Valuesofsecureassetscansometimesbeinferredwithoutdirect access,throughindirectobservationor“snooping”ofintermediatecomputationor communicationsofIPs.Informationflowpoliciesrestrictsuchindirectinference. Anexampleofinformationflowpolicymightbethefollowing.
∙ KeyObliviousness:Alow-securityIPcannotinferthecryptographickeysby snoopingonlythedatafromcryptoengineonalow-securitycommunicationfabric.
Informationflowpoliciesaredifficulttoanalyze.Theyoftenrequirehighlysophisticatedprotectionmechanismsandadvancedmathematicalargumentsforcorrectness, typicallyinvolvinghardnessorcomplexityresultsfrominformationsecurity.Consequentlytheyareemployedonlyoncriticalassetswithveryhighconfidentiality requirements.
Liveness.Thesepoliciesensurethatthesystemperformsitsfunctionalitywithout “stagnation”throughoutitsexecution.Atypicallivenesspolicyisthatarequestfor aresourcebyanIPisfollowedbyaneventualresponseorgrant.Deviationfrom suchapolicycanresultinsystemdeadlockorlivelock,consequentlycompromising systemavailabilityrequirements.
Time-of-CheckVersusTimeofUse(TOCTOU).Thisreferstotherequirement thatanyagentaccessingaresourcerequiringauthorizationisindeedtheagentthat hasbeenauthorized.AcriticalexampleofTOCTOUrequirementisinfirmware update;thepolicyrequiresfirmwareeventuallyinstalledonupdateisthesame firmwarethathasbeenauthenticatedaslegitimatebythesecurityorcryptoengine.
SecureBoot.Bootingasystementailscommunicationofsignificantsecurityassets, e.g.,fuseconfigurations,accesscontrolpriorities,cryptographickeys,firmware updates,debugandpost-siliconobservabilityinformation,etc.Consequently,boot imposesmorestringentsecurityrequirementsonIPinternalsandcommunications thannormalexecution.Individualpoliciesduringbootcanbeaccesscontrol,informationflow,andTOCTOUrequirements;however,itisoftenconvenienttocoalesce themintoaunifiedsetofbootpolicies.
2.4AdversariesinSoCSecurity Todiscusssecurityvalidation,oneofthefirststepsistoidentifyhowasecurity policycanbesubverted.Doingsoistantamounttoidentifyingpotentialadversaries andcharactertizingthepoweroftheadversaries.Indeed,effectivenessofvirtuallyall securitymechanismsinSoCdesignstodayarecriticallydependentonhowrealistic themodeloftheadversaryis,againstwhichtheprotectionschemesareconsidered. Conversely,mostsecurityattacksrelyonbreakingsomeoftheassumptionsmade regardingconstraintsontheadversarywhiledefiningprotectionmechanisms.When discussingadversaryandthreatmodels,itisworthnotingthatthenotionofadversary canvarydependingontheassetbeingconsidered:inthecontextofprotectingDRM keys,theenduserwouldbeconsideredanadversary,whilethecontentprovider(and eventhesystemmanufacturer)maybeincludedamongadversariesinthecontextof protectingprivateinformationoftheenduser.Consequently,ratherthanfocusingon aspecificclassofusersasadversaries,itismoreconvenienttomodeladversaries correspondingtoeachpolicyanddefineprotectionandmitigationstrategieswith respecttothatmodel.
Definingandclassifyingthepotentialadversaryisahighlycreativeprocess.It needsconsiderationssuchaswhethertheadversaryhasphysicalaccesstothesystem,whichcomponentstheycanobserve,control,modify,orreverse-engineer,etc. Recently,therehavebeensomeattemptsatdevelopingadisciplined,cleancategorizationofadversarialpowers.Onepotentialcategorization,basedontheinterfaces throughwhichtheadversarycangainaccesstothesystemassets,canbeusedto classifythemintothefollowingsixbroadcategories(inorderofincreasingsophistication).Notethattherehasbeensignificantresearchintospecificattacksindifferent categories,andacomprehensivetreatmentofdifferentattacksisbeyondthescope ofthischapter;theinterestedreaderisencouragedtolookupsomeofthereferences forathoroughdescriptionofspecificdetails.
UnprivilegedSoftwareAdversary:ThisformofadversarymodelsthemostcommontypeofattackonSoCdesigns.Heretheadversaryisassumedtonothaveaccess toanyprivilegedinformationaboutthedesignorarchitecturebeyondwhatisavailablefortheenduser,butisassumedtobesmartenoughtoidentifyor“reverseengineer”possiblehardwareandsoftwarebugsfromobservedanomalies.Theunderlyinghardwareisalsoassumedtobetrustworthy,andtheuserisassumedtohaveno physicalaccesstotheunderlyingIPs.Theimportanceofthisnaïveadversarialmodel isthatanyattackpossiblebysuchanadversarycanbepotentiallyexecutedbyany user,andcanthereforebeeasilyandquicklyreplicatedon-fieldonalargenumberof systeminstances.Forthesetypesofattacks,thecommon“entrypoint”oftheattack isassumedtobeuser-levelapplicationsoftware,whichcanbeinstalledorrunonthe systemwithoutadditionalprivileges.Theattacksthenrelyondesignerrors(bothin hardwareandsoftware)tobypassprotectionmechanismsandtypicallygetahigher privilegeaccesstothesystem.Examplesoftheseattacksincludebufferoverflow, codeinjection,BIOSinfection,return-orientedprogrammingattacks,etc.[7, 8].
SystemSoftwareAdversary:Thisprovidesthenextlevelofsophisticationtothe adversarialmodel.Hereweassumethatinadditiontotheapplications,potentially theoperatingsystemitselfmaybemalicious.Notethatthedifferencebetweenthe systemsoftwareadversaryandunprivilegedsoftwareadversarycanbeblurred,in thepresenceofbugsintheoperatingsystemimplementationleadingtosecurityvulnerabilities:suchvulnerabilitiescanbeseenasunprivilegedsoftwareadversaries exploitinganoperatingsystembug,oramaliciousoperatingsystemitself.Nevertheless,thedistinctionfacilitatesdefiningtherootoftrustforprotectingsystem assets.Iftheoperatingsystemisassumeduntrusted,thenprotectionandmitigation mechanismsmustrelyonlowerlevel(typicallyhardware)primitivestoensurepolicyadherence.Notethatsystemsoftwareadversarymodelcanhaveahighlysubtle andcompleximpactonhowapolicycanbeimplemented,e.g.,recallfromthemasqueradepreventionexampleabovethatitcanaffectthedefinitionofcommunication fabricarchitecture,communicationprotocolamongIPs,etc.
SoftwareCovert-ChannelAdversary:Inthismodel,inadditiontosystemand applicationsoftware,aside-channelorcovert-channeladversaryisassumedtohave accesstononfunctionalcharacteristicsofthesystem,e.g.,powerconsumption,wallclocktimetakentoserviceaspecificuserrequest,processorperformancecounters, etc.,whichcanbeusedinsubtlewaystoidentifyhowassetsarestored,accessed,and communicatedbyIPs(andconsequentlysubvertprotectionmechanisms)[9, 10].
NaïveHardwareAdversary:Naivehardwareadversaryreferstotheattackerswho maygaintheaccesstothehardwaredevices.Whiletheattackersmaynothave advancedreverse-engineeringtools,theymaybeequippedwithbasictestingtools. Commontargetsforthesetypesofattacksincludeexposeddebuginterfacesand glitchingofcontrolordatalines[11].Embeddedsystemsareoftenequippedwith multipledebuggingportsforquickprototypevalidationandtheseportsoftenlack properprotectionmechanisms,mainlybecauseofthelimitedon-boardresources. Theseportsareoftenleftonpurposetofacilitatethefirmwarepatchingorbugfixingforerrorsandmalfunctionsdetectedon-field.Consequently,theseportsalso providepotentialweaknesswhichcanbeexploitedforviolatingsecuritypolicies. Indeed,someofthe“celebrated”attacksinrecenttimesmakeuseofavailablehardwareinterfacesincludingtheXBOX360Hack[12],NestThermostatHack[13],and severalsmartphonejailbreakingtechniques.
HardwareReverse-EngineeringAdversary:Inthismodel,theadversaryis assumedtobeabletoreverse-engineerthesiliconimplementationforon-chipsecrets identification.Inpractice,suchreverse-engineeringmaydependonsniffinginterfacesasdiscussedfornaïvehardwareadversaries.Inaddition,theycandepend onadvancedtechniquessuchaslaser-assisteddevicealteration[14]andadvanced chip-probingtechniques[15].Hardwarereverseengineeringcanbefurtherdivided intotwocategories:(1)chip-leveland(2)IPcorefunctionalityreconstruction.Both attackvectorsbringsecuritythreatsintothehardwaresystems,andpermitextractionofsecretinformation(e.g.,cryptographicandDRMkeyscodedintohardware), whichcannotbeotherwiseaccessedthroughsoftwareordebugginginterfaces.
MaliciousHardwareIntrusionAdversary:Ahardwareintrusionadversary(or hardwareTrojanadversary)isamaliciouspieceofhardwareinsidetheSoCdesign. Itisdifferentfromahardwarereverse-engineeringadversaryinthatinsteadof“passively”observingandreverse-engineeringfunctionalityoftherestofthedesign components,ithastheabilitytocommunicatewiththem(and“fool”themintoviolatingrequisitepolicies).Notethataswiththedifferencebetweensystemsoftware andunprivilegedsoftwareadversariesabove,manyattackspossiblebyanintrusion adversarycan,inprinciple,beimplementedbyareverse-engineeringadversaryin thepresenceofhardwarebugs.Nevertheless,therootoftrustandprotectionmechanismsrequiredaredifferent.Furthermore,inpractice,hardwareTrojanattackshave becomeamatterofconcernspecificallyinthecontextofSoCdesignsthatinclude untrustedthird-partyIPsaswellasthoseintegratedinanuntrusteddesignhouse. Protectionpoliciesagainstsuchadversariesarecomplex,sinceitisunclearapriori whichIPsorcommunicationfabrictotrustunderthismodel.Thetypicalapproach takenforsecurityinthepresenceofintrusionadversaries(andinsomecases,reverseengineeringadversaries)istoensurethatarogueIP A cannotsubvertanon-rogue IP B intodeviatingfromapolicy.
2.5IP-LevelTrustValidation Onemaywonder,whyisitnotpossibletoreusetraditionalfunctionalverification techniquestothisproblem?ThisisduetothefactthatIPtrustvalidationfocuses onidentifyingmaliciousmodificationssuchashardwareTrojans.HardwareTrojans typicallyrequiretwoparts:(1)atrigger,and(2)apayload.Thetriggerisasetofconditionsthattheiractivationdeviatesthedesiredfunctionalityfromthespecification andtheireffectsarepropagatedthroughthepayload.Anadversarydesignstrigger conditionssuchthattheyaresatisfiedinveryraresituationsandusuallyafterlong hoursofoperation[16].Consequently,itisextremelyhardforanaïvefunctionalvalidationtechniquetoactivatethetriggercondition.Belowwediscussafewapproaches basedonsimulation-basedvalidationaswellasformalmethods.AdetaileddescriptionofvariousIPtrustvalidationtechniquesisavailablein[17, 18].
Simulation-BasedValidation :Therearesignificantresearcheffortsonhardware Trojandetectionusingrandomandconstrained-randomtestvectors.Thegoalof logictestingistogenerateefficientteststoactivateaTrojanandtopropagateits effectstotheprimaryoutput.TheseapproachesarebeneficialindetectingthepresenceofaTrojan.Recentapproachesbasedonstructural/functionalanalysis[19–21]areusefultoidentify/localizethemaliciouslogic.UnusedCircuitIdentification (UCI)[19]approacheslookforunusedportionsinthecircuitandflagthemasmalicious.TheFANCIapproach[21]wasproposedtoflagsuspiciousnodesbasedon theconceptofcontrolvalues.Oyaetal.[20]utilizedwell-craftedtemplatestoidentifyTrojansinTrustHUBbenchmarks[22].Thesemethodsassumethattheattacker usesrarelyoccurringeventsasTrojantriggers.Using“less-rare”eventsastrigger
willvoidtheseapproaches.Thiswasdemonstratedin[23],whereHardwareTrojans weredesignedtodefeatUCI[19].
Side-ChannelAnalysis:Basedonthefactthatatriggerconditionusuallyhas extremelylowprobability,thetraditionalATPG-basedmethodforfunctionaltesting cannotfulfillthetaskofTrojanactivationanddetection.Bhuniaetal.[16]proposed themultipleexcitationofrareoccurrence(MERO)approachtogeneratemoreeffectiveteststoincreasetheprobabilitytotriggertheTrojan.Amorerecentworkby Sahaetal.[24]canimproveMEROtogethigherdetectioncoveragebyidentifyingpossiblepayloadnodes.Side-channelanalysisfocusesonthesidechannelsignatures(e.g.,delay,transient,andleakagepower)ofthecircuit[25],whichavoids thelimitations(lowtriggerprobabilityandpropagationofpayload)oflogictesting. Narasimhanetal.[26]proposedtheTemporalSelf-Referencingapproachonlarge sequentialcircuits,whichcomparesthecurrentsignatureofachipattwodifferent timewindows.Thisapproachcancompletelyeliminatetheeffectofprocessnoise, andittakesoptimizedlogictestsetstomaximizetheactivityoftheTrojan.
EquivalenceChecking:InordertotrustanIPblock,itisnecessarytomakesure thattheIPisperformingtheexpectedfunctionality—nothingmoreandnothingless. Fromsecuritypointofview,verificationofcorrectfunctionalityisnotenough.The verificationengineerhastoconfirmthattherearenootheractivitiesbesidesthe desiredfunctionality.Equivalencecheckingensuresthatthespecificationandimplementationareequivalent.Traditionalequivalencecheckingtechniquescanleadto statespaceexplosionwhenlargeIPblocksareinvolvedwithsignificantlydifferent specificationandimplementation.OnepromisingdirectionistouseGröbnerbasis theorytoverifyarithmeticcircuits[27].Similarto[28],thereductionofspecificationpolynomialwithrespecttoGröbnerbasispolynomialsisperformedbyGaussian eliminationtoreduceverificationtime.Inallofthesemethods,whentheremainder isnonzero,itshowsthatthespecificationisnotexactlyequivalentwiththeimplementation.Thus,thenonzeroremaindercanbeanalyzedtoidentifythehiddenmalfunctionsorTrojansinthesystem.
ModelChecking:Modelcheckingistheprocessofanalyzingadesignforthe validityofpropertiesstatedintemporallogic.AmodelcheckertakestheRegisterTransferLevel(RTL)(e.g.,Verilog)codealongwiththepropertywrittenasa VerilogassertionandderivesaBooleansatisfiability(SAT)formulationforvalidating/invalidatingtheproperty.ThisSATformulationisfedtoaSATengine,which thensearchesforaninputassignmentthatviolatestheproperty[29].Inpractice, designersknowtheboundsonthenumberofsteps(clockcycles)withinwhicha propertyshouldhold.InBoundedModelChecking(BMC),apropertyisdetermined toholdforatleastafinitesequenceofstatetransitions.TheBooleanformulaforvalidating/invalidatingthetargetpropertyisgiventoaSATengine,andifasatisfying assignmentisobservedwithinspecificclockcycles,thatassignmentisawitness againstthetargetproperty[30].ThepropertiescanbedevelopedtodetectTrojans thatcorruptcriticaldataandverifythetargetdesignforsatisfactionofthesepropertiesusingaboundedmodelchecker.
TheoremProving:Theoremproversareusedtoproveordisprovepropertiesofsystemsexpressedaslogicalstatements.However,verifyinglargeandcomplexsystems usingtheoremproversrequireexcessiveeffortandtime.Despitetheselimitations, theoremprovershavecurrentlydrawnalotofinterestinverificationofsecuritypropertiesonhardware.In[31–33],theProof-CarryingHardware(PCH)frameworkwas usedtoverifysecuritypropertiesonsoftIPcores.SupportedbytheCoqproofassistant[34],formalsecuritypropertiescanbeformalizedandprovedtoensurethetrustworthinessofIPcores.ThePCHmethodisinspiredfromtheproof-carryingcode (PCC),whichwasproposedbyNecula[35].Thecentralideaisthatuntrusteddevelopers/vendorscertifytheirIP.Duringthecertificationprocess,thevendordevelops safetyproof forthesafetypoliciesprovidedbyIPcustomers.Thevendorthen providestheuserwiththeIPdesign,whichincludestheformalproofofthesafety properties.ThecustomerbecomesassuredofthesafetyoftheIPbyvalidatingthe designusingaproofchecker.Arecentapproachpresentedascalabletrustvalidation frameworkusingacombinationoftheoremprovingandmodelchecking[36].
2.6SecurityAlongSoCDesignLifeCycle Wenowturntotheproblemofsystem-levelsecurityvalidationfortheSoCdesigns. ThisprocesstakesplaceintheSoCdesignhouseandcontinuesacrossthesystem designlifecycle.Whenperformingsystem-levelvalidation,theconstituentIPsare assumedtohaveundergonealevelofstandalonetrustvalidationbeforeintegration.
Figure 2.4 providesahigh-leveloverviewoftheSoCdesignlifecycle.Eachcomponentofthelifecycle,ofcourse,involvesalargenumberofdesign,development, andvalidationactivities.Here,wesummarizethekeyactivitiesinvolvedalongthe lifecycle,thatpertaintosecurity.Subsequentsectionswillelaborateontheindividualactivities.
RiskAssessment.Securityrequirementsdefinitionisakeypartofproductplanning,andhappensconcurrentlywith(andinclosecollaborationwith)thedefinition ofarchitecturalfeaturesoftheproduct.Thisprocessinvolvesidentifyingthesecurityassetsinthesystem,theirownership,andprotectionrequirements,collectively definedas securitypolicies (seebelow).Theresultofthisprocessistypicallythe generationofasetofdocuments,oftenreferredtoas productsecurityspecification (PSS),whichprovidestherequirementsfordownstreamarchitecture,design,and validationactivities.
SecurityArchitecture.ThegoalofasecurityarchitectureistodesignmechanismsforprotectionofsystemassetsasspecifiedbythePSS.Itincludesseveral components,asfollows:(1)identifyingandclassifyingpotentialadversaryforeach asset;(1)determiningattackerentrypoints,alsoreferredtoasthreatmodeling;and (3)developingprotectionandmitigationstrategies.Theprocesscanidentifyadditionalsecuritypolicies—typicallyatalowerlevelthanthoseidentifiedduringrisk assessment(seebelow)—whichareaddedtothePSS.Thesecuritydefinitiontypi-
Fig.2.4 AtypicalSoClifecyclefromexplorationtoproduction
callyproceedsincollaborationwitharchitectureanddesignofothersystemfeatures, includingspeed,powermanagement,thermalcharacteristics,etc.,witheachcomponentpotentiallyinfluencingtheothers.
SecurityValidation
.SecurityvalidationrepresentsoneofthelongestandmostcriticalpartofsecurityassuranceforindustrialSoCdesigns,spanningthearchitecture, design,andpost-siliconcomponentsofthesystemlifecycle.Theactualvalidation targetandpropertiesvalidatedatanyphase,ofcourse,dependsonthecollateral availableinthatphase.Forexample,wetarget,respectively,architecture,design, implementation,andsiliconartifactsasthesystemdevelopmentmatures.Below wewilldiscusssomeofthekeyvalidationactivitiesandassociatedtechnologies. Onekeycomponentofsecurityvalidationistodeveloptechniquestosubvertthe advertisedsecurityrequirementsofthesystem,andidentifymitigationmeasures. Mitigationmeasuresforearly-stagevalidationtargetingarchitectureandearlysystemdesignoftenincludesignificantrefinementofthesecurityarchitectureitself.At laterstagesofthesystemlifecycle,whenarchitecturalchangesarenolongerfeasibleduetoproductmaturity,mitigationmeasurescanincludesoftwareorfirmware patches,productdefeature,etc.
2.7SecurityValidationActivities Unfortunately,theroleofsecurityvalidationisdifferentfrommostotherkindsofvalidation(suchasfunctionalorpower-performanceortiming)sincetherequirements aretypicallylessprecise.Inparticular,thegoalofsecurityvalidationisto“validate conditionsrelatedtosecurityandprivacyofthesystemthatarenotcoveredbyother
validationactivities.”Therequirementthatsecurityvalidationfocusesontargetsnot coveredbyothervalidationisimportantgiventhestricttime-to-marketconstraints, whichprecludeduplicationofresourcesforthesame(orsimilar)validationtasks; however,itputsonusonthesecurityvalidationorganizationtounderstandactivitiesperformedacrossthespectrumoftheSoCdesignvalidationandidentifyholes thatpertaintosecurity.Toexacerbatetheproblem,asignificantamountofsecurity objectivesarenotclearlyspecified,makingitdifficultto(1)identifyvalidationtasks tobeperformed,and(2)developclearcoverage/successcriteriaforthevalidation. Consequently,thevalidationplanincludesalargenumberofdiverseactivitiesthat rangefromthesciencetotheartandsometimeseven“blackmagic.”
Atahighlevel,securityvalidationactivitiescanbedividedroughlyamongthe followingfourcategories.
FunctionalValidationofSecurity-sensitiveDesignFeatures.Thisisessentially extensiontofunctionalvalidation,butpertaintodesignelementsinvolvedincriticalsecurityfeatureimplementations.AnexampleisthecryptographicengineIP. Acriticalfunctionalrequirementforthecrypographicengineisthatitencryptsand decryptsdatacorrectlyforallmodes.Aswithanyotherdesignblock,thecryptographicengineisalsoatargetoffunctionalvalidation.However,giventhatitisa criticalcomponentofanumberofsecurity-criticaldesignfeatures,securityvalidationplanningmaydeterminethatcorrectnessofcryptographicfunctionalitytobe crucialenoughtojustifyfurthervalidationbeyondthecoverageprovidedbyvanilla functionalvalidationactivities.Consequently,suchanIPmayundergomorerigorous testing,orevenformalanalysisinsomecases.OthersuchcriticalIPsmayinclude IPsinvolvedinsecureboot,on-fieldfirmwarepatching,etc.
ValidationofDeterministicSecurityRequirements
.Deterministicsecurity requirementsarevalidationobjectivesthatcanbedirectlyderivedfromsecurity policies.Suchobjectivestypicallyencompassaccesscontrolrestrictions,address translations,etc.Consideranaccesscontrolrestrictionthatspecifiesacertainrange ofmemorytobeprotectedfromDirectMemoryAccess(DMA)access;thismay bedonetoensureprotectionagainstcode-injectionattacks,orprotectakeythatis storedinsuchlocation,etc.Anobviousderivedvalidationobjectiveistoensurethat allDMAcallsforaccesstoamemorywhoseaddresstranslatestoanaddressinthe protectedrangemustbeaborted.Notethatvalidationofsuchpropertiesmaynot beincludedaspartoffunctionalvalidation,sinceDMAaccessrequestsforDMAprotectedaddressesareunlikelytoarisefor“normal”testcasesorusagescenarios.
NegativeTesting .Negativetestinglooksbeyondthefunctionalspecificationof designstoidentifyifsecurityobjectivescanbesubvertedorareunderspecified. ContinuingwiththeDMA-protectionexampleabove,negativetestingmayextend thedeterministicsecurityrequirement(i.e.,abortionofDMAaccessforprotected memoryranges)toidentifyifthereareanyotherpathstoprotectedmemoryinadditiontoaddresstranslationactivatedbyaDMAaccessrequest,andifso,potential inputstimulustoactivatesuchpaths.
Hackathons.Hackathons,alsoreferredtoas white-boxhacking fallinthe“black magic”endofthesecurityvalidationspectrum.Theideaisforexperthackersto performgoal-orientedattemptsatbreakingsecurityobjectives.Thisactivitydepends primarilyonhumancreativity,althoughsomeguidelinesexistonhowtoapproach them(seediscussiononpenetrationtestinginthenextsection).Becauseoftheircost andtheneedforhighhumanexpertise,theyareperformedforattackingcomplex securityobjectives,typicallyathardware/firmware/softwareinterfacesoratthechip boundary.
2.8ValidationTechnologies Recallfromabovethatfocusedfunctionalvalidationofsecurity-criticaldesigncomponentsformakeyconstituentofsecurityvalidation.Fromthatperspective,securityvalidationincludesandsupersedesallfunctionalvalidationtools,flows,and methodologies.FunctionalvalidationofSoCdesignsisamatureandestablished area,withanumberofcomprehensivesurveyscoveringdifferentaspects[37, 38]. Inthissection,weinsteadconsidervalidationtechnologiestosupportothervalidationactivities,e.g.,negativetesting,white-boxhacking,etc.Asdiscussedabove, theseactivitiesinherentlydependonhumancreativity;tools,methodologies,and infrastructuresaroundthemprimarilyactasassistants,fillingingapsinhumanreasoningandprovidingrecommendations.
Securityvalidationtodayprimarilyusesthreekeytechnologies:fuzzing,penetrationtesting,andformalorstaticanalysis.Hereweprovideabriefdescriptionof thesetechnologies.Notethatfuzzingandstaticanalysisareverygenerictechniques withapplicationsbeyondsecurityvalidation;ourdescriptionwillbeconfinedtotheir applicationsonlyonsecurity.
Fuzzing.Fuzzing,orfuzztesting[39],isatestingtechniqueforhardwareorsoftwarethatinvolvesprovidinginvalid,unexpected,orrandominputsandmonitoring theresultforexceptionssuchascrashes,orfailingbuilt-incodeassertionsormemoryleaks.Figure 2.5 demonstratesastandardfuzzingframework.Itwasdeveloped asasoftwaretestingapproach,andhassincebeenadaptedtohardware/software systems.Itiscurrentlyacommonpracticeinindustryforsystem-levelvalidation. Inthecontextofsecurity,itiseffectiveforexposinganumberofpotentialattacker entrypoints,includingthroughbufferorintegeroverflows,unhandledexceptions, raceconditions,accessviolations,anddenialofservice.Traditionally,fuzzinguses eitherrandominputsorrandommutationsofvalidinputs.Akeyattractiontothis approachisitshighautomationcomparedtoothervalidationtechnologiessuchas penetrationtestingandformalanalysis.Nevertheless,sinceitreliesonrandomness, fuzzingmaymisssecurityviolationsthatrelyonuniquecorner-casescenarios.To addressthatdeficiency,therehasbeenrecentworkon“smart”inputgenerationfor fuzzing,basedondomain-specificknowledgeofthetargetsystem.Smartfuzzing
Fig.2.5 Apictorialrepresentationoffuzzingframeworkusedinpost-siliconSoCsecurityvalidation
mayprovideagreatercoverageofsecurityattackentrypoints,atthecostofmore upfrontinvestmentindesignunderstanding.
PenetrationTesting.Apenetrationtestisanattackonacomputersystemwiththe intentiontofindsecurityweakness,potentiallygainingaccesstoit,itsfunctionality, anddata.Itistypicallyperformedbyexperthackersoftenwithdeepknowledge ofsystemarchitecture,design,andimplementationcharacteristics.Notethatwhile therearecommonalitiesbetweenpenetrationtestingandtestingdoneonfunctional validation,thereareseveralimportantdifferences.Inparticular,roughly,penetration testinginvolvesiterativeapplicationofthefollowingthreephases:
1. AttackSurfaceEnumeration.Thefirsttaskistoidentifythefeaturesoraspects ofthesystemthatarevulnerabletoattack.Thisistypicallyacreativeprocess involvingasmorgasbordofactivities,includingdocumentationreview,network servicescanning,andevenfuzzingorrandomtesting(seebelow).
2. VulnerabilityExploitation.Oncethepotentialattackerentrypointsarediscovered,applicableattacksandexploitsareattemptedagainsttargetareas.Thismay requireresearchintoknownvulnerabilities,lookingupapplicablevulnerability classattacks,engaginginvulnerabilityresearchspecifictothetarget,andwriting/creatingthenecessaryexploits.
3. ResultAnalysis.Iftheattackissuccessful,theninthisphasetheresultingstateof thetargetiscomparedagainstsecurityobjectivesandpolicydefinitionstodetermineifthesystemwasindeedcompromised.Notethatevenifasecurityobjective isnotdirectlycompromised,asuccessfulattackmayidentifyadditionalattack surfacewhichmustthenbeaccountedforwithfurtherpenetrationtesting.
Notethatwhiletherearecommonalitiesbetweenpenetrationtestingandtestingdone functionalvalidation,thereareseveralimportantdifferences.Inparticular,thegoal offunctionaltestingistosimulatebenignuserbehaviorand(perhaps)accidental failuresundernormalenvironmentalconditionsofoperationofthedesignasdefined byitsspecification.Penetrationtestinggoesoutsidethespecificationtothelimitsset bythesecurityobjective,andsimulatesdeliberateattackerbehavior.
Another random document with no related content on Scribd:
3.
The rule is used to find the middle of an edge or surface by placing it across the piece so that the distances from the edges of the piece to corresponding inch, or fractional marks shall be the same, Fig. 3, the middle of the piece being at a point midway between the marks selected.
2. The Try-square.
—The try-square may be made entirely of iron or steel or it may have a head of wood called the beam and a blade of steel. The blade is graduated into inches and fractions of an inch. As all try-squares are liable to be injured by rough usage, care should be taken not to let them drop on the bench or floor, nor should they ever be used for prying or pounding. Fig. 4.
The try-square is used for three purposes: First, to act as a guide for the pencil or knife point in laying out lines across the grain at right angles to an edge or surface; second, to test an edge or end to see whether it is square to an adjoining surface or edge; third, to test a piece of work to see whether it is of the same width or thickness thruout its entire length.
Fig. 5 shows the various positions assumed in lining across a piece. The beam should be held firmly against either the face side or the face edge.
The face side of a piece is the broad surface which is first made true. The face edge is the first edge which is made square to the face side and straight. These two surfaces are usually marked in some way so that they may be distinguished from the other surfaces. Their use is fully explained in Chapter III.
F . 5.
If the beam projects beyond the end of the wood, it should be reversed. The knife should be inclined forward and away from the blade of the try-square slightly. A light, firm line should be made the first time across the piece.
F . 6.
In testing edges or ends for squareness, the beam should be held, as in lining, firmly either against the face side or the face edge. Fig. 6. Care should be taken to test the extreme ends of the piece. Also test at a sufficient number of points to show fully the condition of the edge. Sliding the try-square along the edge is not objectionable if the blade be held lightly on the surface. Under no circumstances should the try-square be used to scrape the wood.
F . 7.
In testing a piece to see whether it is of the same width or thickness thruout its entire length, place the blade across the surface to be tested, holding the beam lightly against the face side or face edge, slide the try-square along the piece with the eye fixed upon the graduations at the outer edge. Fig. 7.
3. The Framing Square.
—Large squares of one piece of steel, called framing squares, are used by carpenters for large and rough work. The long arm is called the blade and the short one the tongue. Fig. 8. In addition to the divisions into inches and fractions of an inch, there is on the blade a board measure table and on the tongue a brace or rafter measure table. This square will be found convenient when “cutting up” stock, also for testing corners of large pieces of furniture and for setting the bevel to various angles.
F . 9.
4. The Bevel.
—The bevel differs from the try-square in having a movable blade. Fig. 9. This blade may be set at any desired angle from 0 to 180 degrees. The manner of using the bevel
is similar to that of the try-square. When adjusting, the blade should be just loose enough to move upon the application of slight pressure. There are various ways of setting the bevel to the required angle. Should the triangle used in mechanical drawing be available, angles of 30 degrees, 45 degrees and 60 degrees are easily obtained by adjusting the bevel to the sides of the required angle.
F . 10.
To set the bevel to 45 degrees by means of the framing square, hold the beam against one of the arms, Fig. 10, and move the blade so that it shall pass through corresponding points on both blade and tongue. Fig. 11 illustrates a method in which no other tools are needed. A line is squared across a board having a straight edge. Equal distances are measured from the point at which the line cuts the edge, the blade then being made to pass through these points while the beam is held tightly against the edge.
F . 11.
For angles of 30 degrees and 60 degrees, square a knife line at right angles to an edge. Fig. 12. Measure from the edge, along this line, or from this line along the edge any given distance. Take twice this distance upon the blade of the bevel and adjust so that a right triangle is formed in which the length of the longest side shall be twice that of the shortest.
5. The Marking Gage.
—The gage is used for laying out lines along the grain of the wood. It consists of a beam, Fig. 13, head, thumb screw, and marking point or spur The spur should be sharpened to a knife point with a file so that it may make a fine smooth line. It should project far enough below the beam so that the beam may be rolled forward in such a way as to bring the spur into the board at a slight angle, when properly marking. It should extend not less than an eighth of an inch and in most cases three-sixteenths of an inch.
F 12
13.
The graduations on the beam are seldom reliable. It is safer to set the gage with the rule by measuring the distance from the spur to the gage block. This is done by holding the gage bottom side up in the left hand. With the right place the end of the rule against the head. Fig. 13. After the screw has been tightened, apply the rule again to make sure of the correctness of the setting.
14
To gage the line, take the tool in the right hand, three fingers grasping the beam, first encircling the head for narrow work, and the thumb back, or nearly back, of the spur. Fig. 14. The head should be kept against one or the other of the face sides. Begin at the end of the piece which is towards you, hold the block firmly against the piece, roll the beam forward until the spur barely touches the surface and make a very light line. Fig. 15 illustrates the manner of raising
the spur from the wood by raising the wrist during the backward stroke. It will be found convenient to hold the piece against the bench stop. This steadies the piece and permits the worker to see how deep the spur is cutting and whether the head is against the face properly. Avoid deep lines. They are inaccurate even if straight and always cause trouble in the making unless the grain of the wood is perfectly straight.
F . 15.
6. The Pencil Gage.
—There are occasions when a pencil-gage marks with sufficient accuracy and is more suitable because its point does not cut the wood, such as in gaging for a bevel. A hole bored thru the beam near one end, just large enough to receive a pencil snugly, will suffice. Fig. 16.
F 16
Fig. 17 illustrates a method frequently used by carpenters. The fingers act as a gage head.
7. Slitting Gage. —A slitting gage is one in which the spur is sharp and strong, and will cut thru soft lumber as thick as one-quarter of an inch. The boards are cut from each side and considerable pressure is required. Sometimes a handle like that of the plane is fastened to the beam near the knife or spur. Fig. 18.
F 17
Slitting Gage
Mortise Gage
Panel Gage For wide boards
F . 18.
8. The Mortise Gauge.
Fig. 18 also shows a mortise gage used in advanced work. It has two spurs, one of
them adjusted by means of the screw at the end of the beam at any desired distance from the stationary one, so that the two sides of a mortise or tenon can be marked at once.
9. The Dividers.
—Dividers, Fig. 19, are used (1) in describing circles, (2) in dividing a given space into a given number of parts, and (3) in marking one member which is to be fitted to another irregular member. Fig. 20 shows the manner of setting the dividers. The thumb-screw should be released so that the legs may be moved without much effort. When the approximate setting has been secured, use the thumb-nut for adjusting to more accurate measurement. In describing circles, the dividers should be held as in Fig. 21 and swung to the right or left as is convenient. They should be leaned forward slightly and an effort made to secure a sharp, light line. For most work the two legs may be sharpened to points. Sometimes one is sharpened like a knife point.
19
F
20.
21.
10. Pencil and Knife.—Pencil lines may be used in getting out stock from rough material and in laying out work on rough surfaces where a knife line would not be visible. Pencil lines should be carefully made, however. The pencil may be used also in marking bevels, curves and in other places where the knife or gage mark would be injurious. Otherwise, the knife and gage should be used. Pencil lines are easiest removed from wood by means of the eraser.
F . 22.
In laying out rough stock, if the first edge is sufficiently straight, it is usual to thumb-gage for width. This is done by holding the pencil at the end of the rule and using the thumb of the left hand as the gage head, drawing the whole towards you with the rule acting as gagebeam. Fig. 22
F . 23.
A straight-edge, a board with a straight edge, is often used in marking out. Mark off the length of the piece of wood required. Mark off the breadth at the end of the board, also mark it near what is to be the other end of the piece. Place the straight-edge on these two marks and draw the line. Fig. 23. The try-square should be used to mark across the grain.
CHAPTER II. S .
11. Saws.
—Saws which are used in cutting across the grain are called crosscut; those which are used in cutting parallel to the grain are called ripsaws. Fig. 24. Upon the blade of a saw, near the handle, will be found a number. This represents the number of points to the inch. Points should not be confused with teeth, for there is always one more point per inch than there are teeth. F 24
To prevent the sides of a cut or kerf from binding the saw, the teeth are bent alternately from side to side, that the opening may be wider than the blade is thick. The saw teeth are then said to have “set.” To do good work, a saw should have no more set than is necessary to allow a free movement. Fig. 25. Damp, spongy lumber will require considerable set, while well seasoned lumber necessitates but little.
