COVER FEATURE - PDF document

0018-9162/01/$10.00 © 2001 IEEE 57 COVER FEATURE ork leading toward the IBM 4758started, arguably, in the 1980s when theniques to build tamper-responsive hard-against software piracy.work, we sought to build a secure coprocessor, Meeting the challenge of building a user-conÞgurable secure coprocessorprovided several lessons in hardware and software development andcontinues to spur further research.Joan G. Dyer IBM T.J. WatsonResearch CenterSean W. SmithWeingart achieved our major goals, but learned through hind-We based the 4758Õs security on an architecture andimplementation validated from manufacture tonot incorporate anything related to the eventual soft-ware. Programming, loading of code, or both are com-pleted outside the factory at the customerÕs discretion.Consequently, when a 4758 leaves the factory, it mustrequires a large quantity, and doesnÕt Þt the general-protocol is performed in the factory to establish an ini-imal software within the 4758Õs ROM. When shipped,  Applications  Environment/OS  Kernel  Loaders Officers  Post  Miniboot IBM Tamper-responding unit Trust Figure 1. Overview ofsorÕs three majorcould alter, and soft-We found the following to be the crucial ingredients neededto build a programmable, secure coprocessor.Relying upon software to react to tampering is too slow. How-ever, this observation implies a well-sealed package and carefuldering areas of storage invisible, protecting areas from tamper, orother constraints do not always allow for. Ideally, the number ofcannot compromise any others. We encountered two problemsHence, for the Federal Information Processing Standards (FIPS)validation procedure, we could only use the hardware to seed aimplementing code load security policy. The layer should be val-layers depend for their own security.Subsequent layers personalize the device. We initially selectedFinally, minimal software in ROM provides for repairs or Design Decisions during the 4758Õs manufacturing phase, and thewith a layerÕs owner. A At each codeload boundary, an ofÞcer and key pairauthenticate loading. The previous layerÕs officering to the new ownerÕs initial public key. The ofÞcernot affect any other coprocessorÕs security. Secrets arepersistent data on behalf of applications, and appli-authorized code in ßash memory. Authorization isto the next layer. The checks run against hardware-enforced ßash contents that are locked read-only by theor ßash contents destroys the 4758Õs secrets. The dam-software, but it could not authenticate itself whenbooted, and the application softwareÕs battery-backedHARDWARE Figure 2 shows the 4758Õs hardware architectureguardian processor.Tamper response respond to tamper. Initialization of each card cannot involvedetermines the 4758Õs personality. Our procedure uses pri-must be a trusted root and a description of the history that canability.General coprocessor and auxiliary processorsable auxiliary processors expand the deviceÕs potential use toother data on the coprocessor, protected directly by the 4758The interface to third parties should be as comfortable as pos-sible. We chose the most suitable operating system available atpler is better. intervention. Tamper conditions include penetrationWe prefer this approach because of its speedÑusinga software solution would be unreliable and too slow.to the outer world. One consequence of the 4758ÕsAn effective solution to this problem requires carefulBattery-backed RAM The coprocessorÕs OS manages BBRAM, which pro-(LBBRAM) protects firmware secrets and is onlyall the 4758Õs battery-backed storage.memory and make areas of LBBRAM completely inac-cessible. A separate guardian processor controls the Host PCI bus controlandFIFOs encryptionstandard math numbergenerator clock securitysensingandresponse processorandPC support backed ROM Figure 2. The 4758Õsbattery-backed RAM,generator, and per-for encrypted data inßash memory. Read ONLYRead ONLY 4758Õs ßash memoryand battery-backed form for building the trust hierarchy. It ensures thatonly authorized Þrmware or software can change therupted code, we can Þx this code and verify the Þx.The number of locks and the memory regions theyprotect are deÞned in hardware. The software layersture must be satisÞed within the locked regions, eventhough we didnÕt know the actual sizes that would beticularly, is an iterative process that doesnÕt always Þtwithin time constraints.However, allowing dynamic increases in trust wouldrequire hardware assistance that wasnÕt feasible withinthe allotted product development time frame.ness generates a nonce, key, or any initial secret.To preserve data across 4758 power cycles andloaded code, signatures used by the Þrmware, spacefor the two software layers, and application data. Weused flash memory for this purpose. No tamper-power to erase ßash contents, so anything stored inlocks, it supports secure boot of the 4758.Þcult. Flash chips provide only sector-level erase, andwe also had concerns about each chipÕs Þnite lifetime.The movable boundary between signed loads and soft-make no assumptions about the hostÕs reliabil-ity, require internal and external bus separation.However, this separation slows data movement.the secure environment, providing a user-super-cured computers. The processorÕs capabilities do notThe 4578 also includes a modular-math chip, a dataThe modular-math chip accelerates various on-card4578Õs potential applications.through the secure coprocessor. Some applicationssuch as streaming media require this feature becausecoprocessorÕs host. However, implementing long-termor DES with alternativeFIRMWARETo emphasize the logical distinction between them,in ROM during the manufacturing process. This codetects the secrets each layer stores, as instructed by theembedded main processor, consistent with the locksÕstate. Inspection can validate the guardian processor, recovery from runtime corruption. ers as trust decreases. Development, testing, andprocessor, which highlights the trade-offand a general-purpose processor.Boot codeThe 4758Õs boot code consists of two logicalcomplex, we relied on a power-on self-test tohopefully, relatively bug-free, while POST 1 containsthe remaining tests and is reloadable, if necessary.We also incorporated this idea into the securityfirmware for the same reasons. We called the codein ROM and the rest in ßash.use, and POST 1 checks the rest. After a power-on orreset, POST 0 always runs Þrst, then Miniboot 0, thenment of the hardware lock setting, generate a uniqueWe placed more complexity, including PKI and out-bound authentication, in the updatable ßash memory.association is established at the manufacturing site.certify the public key of the next owner. Beyond this,an ofÞcer doesnÕt need to know anything about thenext layerÕs contents.tifiers associated with different entities or differentTo establish a signing key, the ofÞcer of the previouscer. The 4758 records this new key the Þrst time theA 4758Õs characteristics can-ing parties. Once a layer has an owner, only thatplacing undue trust in the previous ownerÕs intentionsor security practices. Miniboot deletes an ownerÕsIf a layerÕs owner has signed thecommand and, if necessary, has also provided a cer-tiÞcate validating the public key, miniboot accepts aspeciÞc layerÕs content. No portion of the Þrmware andthe codeloadÕs content. The ratchet mechanism pro-keys, which is stored in the protected part of ßash.TargetingOfÞcers can target their commands to cards withspectrum of control, from individual cards to all, withWe found that targeting individual cards was ben-States had to satisfy export restrictions: The codetracteeÕs control. In the second situation, we neededassociated with the nondebug Layer 2. We built theappropriate command and targeted it to the one cardTrustOfÞcers can establish the conditions under which Once a layer has anowner, only thatprevious ownerÕs security practices. The trust hierarchy depends on knowing a 4758Õssoftware history. If an erroneous or malicious softwareimpossible to detect the potential compromise of cru-in Layer 1 in the IBM Þrmware, in which the tamper-results in adding a new certiÞcate to the chain-keep-ing history. With Model 2, we implemented Òoutboundor impersonate a more trusted entity because changesand provide that information to any partner. The part-sion that Layer 1 is aware of the characteristics ofSOFTWARE Two layers give a 4758 its runtime personality.the actions that will be taken with respect to Layer 3.Þgurability was important because some of the 4758Õsing, which limits the actual memory to what is phys-ically present within the coprocessor.been designed from the start for security ratherbeen a better choice, provided that it offered aWe expanded CP/Q to include device driversfor the 4758Õs hardware. We call the resultingoperating environment CP/Q++. CP/Q++ is wellsuited to the modular coding style the 4758Õsapplications while working at multiple sites. Moreover,we could leverage plenty of local expertise because someaddress-space separation made it somewhat easier toÞnd and Þx integration problems. CP/Q++ also simpli-ment period.We needed to choose which pieces to build into Layer2, which were always loaded and started, and whatprivileges and resources to allow each module. We usedCP/QÕs builder and system-level debugger internally todevelopment phase in particular, we used the debuggerdidnÕt always recognize that we needed to view the con-Þguration Þle as part of the code base.to optimize system throughput, a fairly easy task givenCP/QÕs conÞgurability. However, we could only esti- 4758, we did not Þnd purpose OS. requests, and results. We selected what seemedto be a minimal design, always initiated fromanother via a 16-byte agent ID. We used mail-col with a host device driver, a communicationsenough to allow experimentation with otherdata transfer. However, it is not a familiar par-We subdivided the software into two sublayersÑits own independent keys. Various customers haveThe programming environment has complexities ofFurther, Miniboot 1 makes some guarantees regard-For example, Miniboot 1 increments the ratchet so thatLayer 2 is unable to write to Layer 3Õs ßash area, eventhough the guardian processorÕs policy, shown incan erase all sectors. However, it precludes using Layerface that requires the cooperation of Miniboot 1. Tothe certificate chain that traces all updates to thetion history, which allow the entityÕs potential part-visor-level code and will load, at most, one user-levelapplicationÑwhich is insufficient for some experi-ing additional supervisor and user-level code. Insteadof acquiring and learning the CP/Q conÞguration andmand acts as the authenticator. This approachlems associated with modular, extensible OSs.under development. However, the assumptionsMiniboot makes with respect to the division into twoownersÑLayers 2 and 3Ñare tested, with a few sur-To ease the learning curve for 4758 applicationWe considered several factors, including thetime environment. We constructed an extendedand various means for the probe to use either the PCIbus or the serial port to converse with the host.We supported the C programming language and4758Õs unique hardware. If the internal API proved inad-equate, we provided no means to enhance CP/Q++.Given the relatively lengthy download time, wereside on the host, but we didnÕt give that effort ahigh priority. In a production 4758, we cannot short-bypass the FIPS testing done in Miniboot and POST. very goodsuch as using for data transfer. We designed the 4758 so that third parties couldwrite their own applications without IBMÕs involve-ment, approval, or even knowledge. We believe thecoprocessor to provide this facility. Several applica-ing, use the initial application, IBMÕs CCA. The 4758ples, a more mainstream coding environment, and abetter-publicized API might have encouraged wider¥a lifetime-secure tamper-responding device,rather than one that is secure only between resetsthat deployment-specific security officers per-¥a secure booting process in which each layer pro-gressively validates the next less-trusted layer,¥an actual manufacturable productÑa nontrivial¥the Þrst FIPS 140-1 Level 4 validation, arguably¥a multipurpose programmable device based on a99-MHz 486 CPU internal environment, with aWe are continuing to build on the success of the4758 project. Currently, we are pursuing work onsystem and applications from the host for faster devel-opment. We are also exploring other embeddedprocessors, such as the Power PC 405GP, We acknowledge the pioneering work ofLiam Comerford and Steve White, the subse-quent efforts of Doug Tygar and Bennet Yee,the helpful advice and hard work of VernonAustel, Suresh Chari, Bob Gezelter, JuanGonzalez, Paul Karger, Pankaj Rohatgi, DaveToll, and the IBM development teams inCharlotte, Poughkeepsie, Vimercate, Lexington,and Austin. Finally, we acknowledge thePalmer, without whom this effort would have 1.S. Weingart, ÒPhysical Security for the microABYSS Sys-Press, Piscataway, N.J., 1987, pp. 52-58.2.S. White and L. Comerford, ÒABYSS: A Trusted Archi-Proc.IEEE Symp.3.S. Smith and S. Weingart, Programmable Secure Coprocessor, ence, New York, 1999.4.J. Dyer et al., ÒApplication Support Architecture for aHigh-Performance, Programmable Secure Coprocessor,ÓProc. 22nd NatÕl Information Systems Security Conf.National Computer Security Center, Ft. George G.5.M. Lindemann and S. Smith, 21798, IBM T.J. Watson Research Center, Hawthorne,N.Y., 2000.6.C.S. Jutla, ÒEncryption Modes with Almost Free Mes-sage Integrity,Ó to be published in 7.Toolkit Code Distribution, http://www.alphaworks.8.Toolkit Documentation, http://www.ibm.com/security/cryptocards (current Sept. 2001).9.Security Enhanced Linux, http://www.nsa.gov/selinux10.IBM PowerPC 405GP/CR, http://www.chips.ibm.com/T.J. Watson Research Center, Hawthorne, New York.Dyer received a PhD in mathematics from New YorkUniversity. Contact her at joandy@watson.ibm.com.IBM T.J. Watson Research Center. His work centers We designed theIBMÕs involvement, knowledge. hardware architecture. He is EPA certiÞed. Contacthim at markl@watson.ibm.com.IBM T.J. Watson Research Center. His research inter-computer science from University of Texas, Austin.T.J. Watson Research Center. His research interestsinclude network security, general-purpose secure run-tributed applications. Sailer received a PhD inengineering from the University of Stuttgart, Ger-many. Contact him at sailer@watson.ibm.com.IBM T.J. Watson Research Center. His research inter-ests include security and operating systems. Van Doornreceived a PhD in computer science from Vrije Uni-the ACM, and Usenix. Contact him at leendert@ Sean W. Smith,currently on leave from the IBM T.J. Watson ResearchCenter. His research focuses on the practical and the-systems. Smith received a PhD in computer sciencefrom Carnegie Mellon University. He is a member ofthe ACM and Usenix. Contact him at sws@cs.dart-Steve Weingart packaging. Weingart received a BSEE from the Uni- New for 2002!Wireless, and Distributed ApplicationsBluetooth have made pervasive computing a reality. Newonline faster than ever. To help you keep pace, the IEEEapplications, includingMobile computingSecurity, scalability, and reliabilityhttp://computer.org/pervasiveIEEE Transactions on Mobile Computingsuch asMobile computinghttp://computer.org/tmc