Attestation Infrastructures for Private Wallets
AAttestation Infrastructures for Private Wallets
Thomas Hardjono
MIT Connection Science & EngineeringCambridge, MA 02139, [email protected]
Abstract —In this paper we focus on one part of trust infras-tructure needed for the future virtual assets industry, namely the attestation infrastructure related to key management in privatewallet systems. Our focus is on regulated private wallets utilizingtrusted hardware, and the capability of the wallet to yieldattestation evidence suitable to address requirements in severaluse-cases, such as asset insurance and regulatory compliance. Weargue that attestation services will be needed as a core part of thekey management lifecycle for private wallets in true decentralizedsystems.
Index Terms —blockchains, trusted computing, wallets, attes-tations, cryptography.
I. I
NTRODUCTION
The nascent virtual assets and cryptocurrencies industryis today facing a number of challenges, not only related totheir business models and to regulatory compliance, but alsochallenges coming from the traditional banking and financialservices sectors. The entrance of banks into the virtual/digitalassets space will further shape the direction of the industry aswhole.Compared to the traditional financial industry – which hasdeveloped and evolved since the introduction of computerizedtrades in the 1960s – the virtual assets industry still lacks the trust infrastructures that permit decentralized systems such asblockchains and Digital Ledger Technology (DLT) systemsto compete with (and perhaps eventually replace) the legacysystems in the traditional financial sector.In this paper we focus on one part of trust infrastruc-tures, namely the attestation infrastructure related to keymanagement in private wallet systems (i.e. unhosted wallets).Our focus is on the regulated private wallet utilizing trustedhardware, and the capability for the wallet to attest evidencethat can be used to address needs in several use-cases and tosatisfy regulatory compliance. Thus, as part of the future trustinfrastructure for decentralized systems, attestation serviceswill be needed as a core part of the key management lifecyclefor hardware wallets. It is insufficient to merely deploy trustedhardware for wallets, as there must be the means (mechanisms,protocols and standards) to: (i) permit wallets to truthfullyreport its system state and the presence of certain types ofkeys inside the trusted hardware (without disclosing the privatekeys) [1], [2], and for (ii) attestation verification services tocorrectly appraise these evidences [3], [4].In the next section we provide some background as to thestate of centralized exchanges, decentralized exchanges andthe entrance of traditional banks into the virtual assets andcrypto-currencies is market. In Section III we provide a short description of the terminology used in the paper. We make thecase for the attestations of private wallet systems in Section IV.An attestation verification service offered by an entity (e.g.VASP) should be part of a broader compliance managementservices offered by the entity. This is discussed in Section V.We explain the components or parts of the attestation infras-tructure and services in Section VI, followed by a high-leveloutline in Section VII of the process of attestations of a wallet.In Section VIII we describe some types of obtainable evidencethat may be relevant to third-parties, such as asset insuranceproviders. We close the paper with some conclusions.Our goal is to make this paper readable to a broad audience,bearing in mind that device attestations based on trustedhardware is a complex subject which is undergoing evolution.Although new types of trusted hardware are entering themarket, we use the example of the humble TPM chip [5] in ourdiscussion because it incorporates many of the fundamentaldesigns in trusted computing [6], including attestations. Weassume the reader is at least familiar with how blockchainsystems generally function.II. B
ACKGROUND
The Bitcoin model [7] promised a peer-to-peer electroniccash system that relied on a network of nodes, essentiallyproviding a distributed processing model. The proposition isthat instead of relying almost exclusively on financial insti-tutions – serving as trusted third parties to process electronicpayments – the use of the peer-to-peer payment system wouldoffer decentralization of control away from these traditionalfinancial institutions.
A. CEX and Centralization
The difficulty of managing keys on the part of end-users hasgiven rise to the hosted wallet (custodian) model, where theasset service provider – commonly referred to as centralizedcrypto-exchanges (CEX) – holds and manages the private-public key pairs of their customers. Current examples of cen-tralized crypto-exchanges include Binance, Coinbase, HuobiGlobal and Kraken [8]. From a regulatory perspective, entitiessuch as centralized crypto-exchanges are referred to as
VirtualAsset Service Providers (VASP) [9].The function of the CEX among others is to hold andmanage the user’s private-public key pair and utilize the key-pair on behalf of the user to sign transactions. A furtherspecialization is the case where the user (as the customerof the CEX) simply opens an account at the CEX entity1 a r X i v : . [ c s . CR ] F e b ithout being associated with any user-specific private-publickey pair. In this commingled accounts arrangement, the CEXperforms transactions on behalf of the customer using the key-pair belonging to the CEX entity.Needless to say, the idea of a centralized CEX goes againstthe very heart of the decentralization of control as envisionedby Nakamoto [7] and also by Chaum [10]. The idea of “peer-to-peer” means that users must be able to deal with one anotherdirectly, without the mediation of any third party. B. AML/CFT and Traditional Banks as New Entrants
With the green light given by the US OCC (Office ofthe Comptroller of the Currency) in July 2020 to allownational banks to provide cryptocurrency custody services forcustomers [11], many CEX entities now face the businesschallenge from banks entering the “hosted wallet” market [12],[13].The traditional banking and financial services sector has anumber of advantages over many newly-emerged CEX entities,notably in the area of regulatory compliance in connectionwith Anti-Money Laundering/Combating the Financing ofTerrorism (AML/CFT). One specific aspect of AML/CFT con-cerns to the need for financial institutions to obtain, validateand exchange customer information in the context of fundstransfers and correspondent banking. The Financial ActionTask Force (FATF) – as the intergovernmental organizationtasked with developing and evolving policies to combat moneylaundering – has placed virtual assets , including crypto-currencies, under the same funds
Travel Rule in its 2019published Recommendations No. 15 [9] and guidelines [14].In practical terms, this means that like traditional banks,the CEX entities and other types of VASPs must now obtainand validate their customer information (for both legal personsand organizations) and to share this information with eachother in the case of virtual asset transfers. The customersender and receiver information, among others, include: (i)the name and account number of the originator (sender),(ii) the address of the originator, (iii) the amount and dateof execution of the funds transfer, (iv) the identity of thebeneficiary’s (recipient) financial institution, (v) the name andaddress of the beneficiary, (vi) the account number of thebeneficiary and other beneficiary identifier, and (vii) the name,address and numerical identifier of the originator’s financialinstitution [15]. Compliance to the funds Travel Rule is alreadythe expectation in the United States [16], and the urgency ofthe matter is highlighted by the size and nature of activitiesrelated to cryptocurrencies (e.g. nearly three quarters of bitcointhat moved in exchange-to-exchange transactions was cross-border in the first half of 2020 [17]).It is worth noting that traditional banks and financial insti-tutions have had to comply to the Travel Rule since at leastthe mid-1990s due to the introduction of the Bank SecrecyAct (BSA) of 1996. Thus, over the past two decades theyhave developed the information infrastructure to deal with thecollection and verification of customer information. They havealso developed the infrastructure needed to securely deliver the originator and beneficiary customer information in relation tointernational funds-transfers and correspondent banking (e.g.SWIFT network [18], [19]). The hosted wallets model and thecommingled-accounts model can be readily replicated (andimproved) by the traditional banks – these institutions havebeen “hosting” people’s money for centuries.Thus, today it is insufficient for CEX entities and VASPsto merely be “cryptocurrency transmitters”. They must alsodevelop new infrastructures that assist them, among others,in complying to AML/CFT regulatory requirements. At thesame time, these new infrastructures must also address thebusiness challenge arising for the emerging
DecentralizedCrypto Exchanges (DEX) – which by definition require itsparticipants to hold their private-public key pair [20].
C. Private Wallets: Asset Risk Management
Fulfilling the vision of the decentralized peer-to-peer elec-tronic cash system as envisioned by Nakamoto [7] necessitatesthe decentralization of control of private keys. That is, it neces-sitates end-users holding and controlling their private keys intheir wallets with trusted hardware. Aside from the protectionof private-keys in these tamper-detectable hardware and thekey management lifecycle of these keys, there are a numberbusiness challenges arising from the fact that private-keys(bound to virtual assets) are now distributed across hundreds ofthousands (even millions) of endpoints. One notable businesschallenge pertains to the ability for these virtual/digital assetsto be insured against theft and loss, which in this case meansrisk of theft/loss of keys from millions of private wallets.One promising avenue to begin addressing this asset insur-ance challenge for private wallets is that of device attestations capabilities offered by some types of trusted hardware (e.g.TPM [5], [21], [22], SGX [23], [24], TrustZone [25], etc.).Attestations is the process by which the trusted hardware (e.g.chip) provides signed evidence regarding its internal state,including the keys present in the shielded locations insidethe hardware without revealing the private-keys [26]. Thisattestations capabilities permits external entities, such as assetinsurance providers, to obtain assurance that (i) private-keysbound to virtual assets are currently located in a given trustedhardware inside a wallet, (ii) that the wallet is in possessionof the user, and (iii) that extracting the private-key from thetrusted hardware will be time consuming and economicallycostly for the attacker who steals the wallet device.These capabilities in-turn permit asset insurance providersto more accurately perform risk assessment over the vir-tual/digital assets tied to specific user wallets. Factors thatare of interest in risk assessment include, but not limitedto: (a) the type of trusted hardware employed in the wallet,(b) evidence that actual hardware is being utilized (versus avirtualized [27] or software-emulated hardware [28]), (c) thetype of computer system within which the trusted hardwareis utilized, (d) known weaknesses and history of successfulattacks on the family of trusted hardware, and (e) the currentvalue of assets tied to the keys inside the trusted hardware.2 ig. 1. Overview of Wallet Attestation Flows
Core to these functions is device attestations performed bythe trusted hardware as the attester.Currently, the market for hardware wallets is still nascent,with a handful of products available for end-users and en-terprise customers (e.g. Ledger’s Nano X [29] using Arm Se-cureCore [30], Silo from Metaco [31]). Several research effortsare continuing on employing secure enclaves technology forwallet purposes (e.g. [32]).On a historical note, it is worth noting that low-costcryptographic hardware have been available for consumer PCcomputers since the mid-2000s, in the form of the TrustedPlatform Module (TPM) version 1.2 chip [5]. A landmarkevent occurred in 2006 when the US Army mandated all itsPC purchases to contain the TPM chip [33]. This spurredmany PC computer OEMs (such as Dell and Hewlett-Packard)who sell into the US federal market to begin incorporatingthe TPM chip inside their mid-range to high-end laptops andPC computers. This demand from the OEMs in turn providedTPM hardware vendors (such as Intel, STMicro and Infineon)with a return on their investment in trusted computing tech-nologies, which they had made since 1999 when the TrustedComputing Group (TCG) industry consortium was established.Applications of the TPM chip in PC computers include file en-cryption (e.g. Microsoft BitLocker [34]), pairing with externalencrypted disk-drives (e.g. Seagate Black Armor [35], [36]),and protecting email signature keys [37]. The current versionis TPM version 2.0 [21], [22].Although more advanced trusted hardware technologiesexist today (e.g. Intel SGX [23], [24], Arm TrustZone [25],Microsoft Pluton [38]), the TPM chip is already widely avail-able (and currently underutilized) in several hundred millionPC computers and related devices.III. T
ERMINOLOGY
In the current work we use existing terminology as far aspossible. For readers seeking a basic definition of many of theterms related to blockchain technology, we recommend theNIST guidance document on blockchain technology [39]. • Virtual Asset Service Provider : We use the definition ofthe VASP provided by FATF [9]. Virtual asset serviceprovider means any natural or legal person who as abusiness conducts one or more of the following activitiesor operations for or on behalf of another natural orlegal person: (i) exchange between virtual assets and fiatcurrencies; (ii) exchange between one or more forms ofvirtual assets; (iii) transfer of virtual assets; (iv) safekeep-ing and/or administration of virtual assets or instrumentsenabling control over virtual assets; and (v) participationin and provision of financial services related to an issuer’soffer and/or sale of a virtual asset. In this context ofvirtual assets, transfer means to conduct a transaction onbehalf of another natural or legal person that moves avirtual asset from one virtual asset address or account toanother. • Hosted wallets : “A hosted wallet is an account-based soft-ware program for storing cryptographic keys controlledby an identifiable third party. These parties receive, store,and transmit cryptocurrency transactions on behalf oftheir account holders; the account holder generally doesnot have access to the cryptographic keys themselves”(US OCC Interpretive Letter • Private wallets (unhosted wallets): Broadly speaking, an unhosted wallet is one where the owner of a cryptocur-rency maintains control of the cryptographic keys foraccessing the underlying cryptocurrency [40]. • Regulated private wallets : A private wallet is consideredto be regulated when the ownership of the wallet isclear and provable using suitable technical means [41].A regulated private wallet can be owned by an individualor organization (e.g. corporation). • VASP-associated regulated private wallets : A regulatedprivate wallet is associated with a VASP when the legalowner of the wallet has registered the wallet and public-key(s) to an account at a regulated VASP. The VASPmust have obtained and validated the customer data forthe account (per the Travel Rule) before permitting theassociation between the wallet and the account. The term regulated VASP is used in the sense of FINMA [41]. • Unverifiable private wallets : A wallet whose legal owner-ship, key-control and technological embodiment is unableto be verified. • Attestation : Attestation is a process for vouching for theaccuracy of information that describes the properties andbehavior of the target protected capabilities or shieldedlocations [5], [42]. The integrity of the target is estab-lished by checking the provenance of its origin and/or byverifying the veracity of state transitions from its original(origin) state to its current state [43]. Attestations of aremote device often provides cryptographic evidence ofthe integrity of firmware, software and configuration thatis operational in a device. • Attestation Evidence : Evidence is typically in the formof an authenticated list of digests of values and actualvalues. Evidence must be unambiguously associated with3he target device; this is often achieved using a crypto-graphic identifier that is physically bound to the device.Conceptually, attestation evidence is usually organizedto provide proof of a series of secure operational statetransitions from one trustworthy environment to anotherstarting with the root of trust for measurement [5]. • Attestation Verification : Verification of attestation evi-dence is determined by examining endorsements (i.e.manufacturer’s cryptographic statements about the de-vice, such as its identity), then comparing signed evidencewith authenticated expected values, all done in a separatetrusted environment (referred to as the “Verifier”) [43].IV. M
AKING THE C ASE FOR A TTESTATIONS OF W ALLETS
One of the major challenges for the digital asset industryrelates to addressing the various attacks aimed at the clientendpoints which hold private-keys. This need for key pro-tection is part of the larger need for a comprehensive keymanagement lifecycle [44], [45] for the different types ofscenarios and use-cases related to blockchains generally. Thechallenge can be expressed in the following, albeit simplistic,terms: certain legitimate third-parties need some degree of visibility into the state of a given wallet system (hardware,firmware, software) [46], but without visibility to the private-keys located within the wallet system. Furthermore, this mustbe performed without affecting the privacy of the user/ownerof the wallet.The following are two use-cases that are emerging in thenear horizon: • Asset insurance providers : An interesting case pertainsto funds insurers [47]–[49] who may wish to enter thevirtual assets and cryptocurrencies market in order toexpand their business coverage. We refer to these entitiesas Asset Insurance Providers (AIP) generically. Theirprimary interest is to obtain some visibility into the stateof a target wallet as part of managing risks associatedwith providing insurance to the assets bound to thekeys in the wallet. Clearly, these third-parties must notobtain access to (see) the private-key in the target wallet.However, they need to obtain assurance that: (i) theprivate-key is present in the wallet and that (ii) sufficientprotection is being utilized in the wallet to protect theprivate-key (e.g. wallet uses real trusted hardware, notemulated). • CBDC Distributors : A crucial use-case coming on thehorizon pertains to
Central Bank Digital Currencies (CBDC) [50], [51] and the various
Stablecoins that maybe derived from fiat digital currencies [52], [53]. As-suming that large financial institutions (e.g. commercialbanks) hold and distribute CBDCs to entities downstream(e.g. smaller regional banks), these CDBC distributorswill need to manage the cryptographic keys in enterprise-grade wallet systems (e.g. with Hardware Security Mod-ules). In this case, the wallet systems of a CDBC-distributor must be able to yield evidence that it is ina healthy state [54], operating using all the components (hardware, software, firmware) it is designed to operatewith.Note that other forms of trusted hardware (e.g. [38], [55],[56]) may be used for enterprise-level private wallets which aredesigned to be non-mobile and be integrated into the corporatedirectory services.Emerging VASPs maybe in a good position today to provideattestation verification services for a variety of use-cases. Thisis because in many use-cases there is a requirement that theverifier entity be a neutral entity (not a wallet manufacturer,not a hardware/software vendor). The attestation related ser-vices should be part of a broader comprehensive managedcompliance services from VASPs.V. M
ANAGED C OMPLIANCE S ERVICES
From the business opportunity perspective, VASPs generallyneed to view their business function as more than simply beingcryptocurrency (asset) transmitters – namely the blockchainanalog of the traditional wire-transfer shops. VASPs need toidentify new types of services which can be offered to theseprivate-wallet owners (both individuals and organizations)that can provide business value to them. There are severalopportunities which we place under the umbrella of managedcompliance services. Several types of offerings can be madeto these owners of private wallets: • Certificate management services for public-keys : VASPscould offer digital certificate management services forthe public-keys of the user employed on the blockchain(i.e. to sign transactions destined for blockchain). Actingin the role of a
Certification Authority the VASP canissue an X.509 certificate [57], [58] for the transactionsigning public-keys of the user. Depending on the trustedhardware capabilities in the wallet, the hardware caninternally generate a private-public key pair, followed bythe user registering this public-key at the VASP to obtainan X.509 certificate.This transaction public-key certificate could be chained-up to the Root CA certificate belonging to the VASP itself(acting as the CA), thereby permitting any recipient ofthe wallet-owner’s X.509 certificate to identify the VASPthat provided the certificate management services to theowner of the private wallet [16]. • Travel Rule compliance services : One of the key chal-lenges with regards to the Travel Rule is the oft-occurring situation where the user (originator) lacks in-formation/data regarding the beneficiary. For example,the typical originator may only know the beneficiary’spublic-key, name and email address (and perhaps theirapproximate geographic location). Thus, for honest usersemploying private wallets, the burden of complying to theTravel Rule lies with them – something that the ordinarycitizen may find difficult and costly to achieve. VASPscould play a crucial role in providing Travel Rule relatedservices to the owners of private wallets.For example, a VASP could offer services pertaining tothe look-up and validation of beneficiary information in4he context of transactions to be sent by the wallet. Forany given beneficiary address (public key), the wallet canquery the VASP’s database prior to transacting on theblockchain in order to ensure that the beneficiary is alegitimate entity (i.e. legal person or organization). • VASP tracking, audit and reconciliation services : Forowners of private wallets who wish to comply to thevarious regulations pertaining to virtual assets, a VASPcan perform tracking of all transactions on the blockchainperformed by one or more keys in the private wallet. Thisis notably relevant to private/permissioned blockchain andDLT systems.Currently, many users employ token-tracking software(e.g. EtherScan for the Ethereum platform) which simplyscans through the confirmed blocks of the ledger to lookfor the user’s public-key. This manual process may notscale well if the user is active on multiple blockchains si-multaneously. VASPs have the opportunity to assist theseusers in performing audit and reconciliation between thewallet key-usage log with the history of user’s transactionon these blockchains. This audit process lends itself tothe VASP proving (e.g. to regulatory authorities) thecompliant status of the user (customer). It also providesa means for the customer to satisfy taxation requirementsthat may arise from asset transfers. This is illustrated inFigure 2. • Attestation services for private wallets : VASPs can pro-vide attestation services – notably the evidence verifierservice – to aid their customers in managing their privatewallets. This is discussed further in Section VII.VI. I
NFRASTRUCTURE FOR A TTESTATIONS
Although the subject matter of attestations (or remote at-testations) is over two decades old now [1], [6], it has onlyrecently reached the mainstream narrative of system healthin cybersecurity. This interest has arisen on several fronts,notably in the context of the trustworthy supply chains forthe provenance of electronic components [59]–[61]. Giventhe spate of recent hacks (e.g. [62], [63]) the provenance ofcomponents is core to cybersecurity more broadly.In brief, an attestation service requires at least the followingcomponents: • Supply chain of endorsements : Components manufactur-ers need to issue endorsements of their products and tomake these signed endorsements data-structures [3], [4]readily accessible to the verifier function and the entityimplementing verifier services. • Verifier function by attestation verification providers : Thefunction of the verification of evidences (yielded by a tar-get attester device) must be performed by a neutral entity,referred to here as the attestation verification provider(AVP). The AVP must collect, collate and validate allthe relevant endorsements coming from the componentmanufacturers of systems. Neutrality means that vendorscannot be an acceptable verifier for their own products.Thus, for example, the manufacturer of a PC computer (e.g. PC OEM) or wallet system should not be appraisingits own endorsements.Today the role of the attestation verification provideris still being defined, and no such service exists as yet. • Attester capabilities in hardware components : Certaintypes of components need to possess the attester capabil-ity so that it can report on its integrity status. Thus, forexample, future motherboards, system on chips (SoC) andrelated electronics should have native attester capabilities.Currently, efforts are underway in the semiconductorindustry to begin addressing the need for trusted supplychain traceability (e.g. Global Semiconductor Alliance(GSA-TIES) [64]).VII. S
UMMARY OF A TTESTATIONS P ROCESS
The need for better visibility into the state of a wallet systemis a common desire on the part of owners of private walletsand of third-parties that provide insurance against the loss andtheft of virtual asset (i.e. loss/theft of keys). Users as walletowners want assurance that their wallet system – a complexcomputer system in its own right – is behaving as designedand is performing its main function (protecting keys).Some legitimate and authorized third-parties (such as assetinsurance providers) require in-depth proof regarding the statusof private-keys in wallets, beyond simply the classic proof-of-possession (PoP) of the private key – which can easilybe obtained by running a challenge-response protocol (e.g.CHAP protocol [65]) against the wallet. Stronger proof isneeded because the challenge-response protocol only showsthat the user is in possession of the private-key – it doesnot show where (i.e. which hardware) the private-key residesin. A dishonest user can simply employ any PC computer tosign the challenge (in the challenge-response protocol) andthen immediately claim loss of the private-key in order torepudiate the signature. Thus, evidence is needed to showthat the private-public key pair (i) originated from within thetrusted hardware, (ii) that the private-key is not visible to theowner of the private-wallet and (iii) that the private-key isnot exportable from the trusted hardware (i.e. the private-keyis hardware-bound and non-migrateable [5], [37]). Using thespecific example of the TPM hardware, some keys that aregenerated by the TPM can be configured upon creation tobe bound to that specific TPM instance. This means that theTPM hardware will subsequently deny any request to move orexport the key from the TPM. Such a key can also be used to“certify” application-level key pairs, permitting these key pairsto be linked to the parent non-migrateable key. A discussionon the TPM key hierarchy is beyond the scope of the currentwork, and the reader is directed to [66] for further descriptionin the context of wallets.There are a number of technical-trust requirements thatdistinguish systems which are attestable from those that areimplicitly trusted. The requirements include, among others,that (1) the properties of the system that affect its behaviorcan be enumerated (i.e., trustworthiness attributes); (2) the5rustworthiness attributes can be expressed in a machine-readable form; (3) the vendors or other trusted sources canvouch for trustworthiness attributes; and that (4) the enumer-ated trustworthiness attributes can be reconciled with attributesprovided by a trusted source [43].An overview of the attestation flow of a wallet device isshown in Figure 1, with the VASP taking the role of the
Verifier and an Asset Insurance Provider taking the role ofthe
Relying Party [43]. The customer possessing the wallet isassumed to have created an account at the VASP, includingregistering the relevant public-keys (to be used by the wallet)to that account. In Step 1 the insurance provider requests thatthe user’s wallet system provide attestation evidence regardingthe wallet system state, including keying material present inits trusted hardware. This request could be regular (e.g. daily,weekly), or it could be triggered by some action on the partof the user (e.g. Insurance Provider notices large transactionon the blockchain originating from the registered public-key).In Step 2 the wallet system as the attester yields a signedevidence and conveys it to the VASP as the verifier. Note thata generic term for the verifier is also the attestation verificationprovider (AVP). In Step 3 the VASP as the verifier appraisesthe evidence from the attester, and then delivers to the RelyingParty the attestation result based on the policies configured atthe VASP. An example of a generic attestation verificationprovider is outlined in [67].Also relevant in Figure 1 is the signed endorsements fromthe wallet manufacturer (acting as the endorser ) for the var-ious components that constitute the wallet. This is shown asStep (a) and Step (b), and occurs out-of-band from the deviceattestation and evidence conveyance flows.VIII. R
ELEVANT E VIDENCE FROM W ALLETS
Depending on the specific type of trusted hardware, thereare a number of evidence types that can be conveyed withthe appropriate attestation protocol. The following is a non-exhaustive list of some of the possible wallet and key infor-mation that can be obtained using attestations [43]: • Key creation provenance : Most (if not all) current genera-tion crypto-processor trusted hardware have the capabilityto create/generate a new private-public key pairs insidethe shielded location of the hardware, and to maintainkeys inside its long-term non-volatile protected storage.Furthermore, evidence regarding this process can beyielded by the trusted hardware, allowing the provenanceof such keys to be asserted.Key-provenance evidence is useful for VASPs in manyuse-case scenarios. For example, in the case of a newlyon-boarded customer bringing their existing wallet sys-tem, the VASP may wish to ascertain the provenance ofthe keys in that wallet. If the provenance of the existingkey-pair in the wallet is unverifiable, then the VASP mayrequire the customer (i.e. wallet) to generate a new key-pair inside the wallet. (assuming the wallet hardware isapproved by the VASP). This, provides the VASP witha clear line of responsibility and accountability (starting
Fig. 2. Overview of VASP reconciliation of wallet-originated transactions with the new key-pair in the customer wallet). The VASPhas exculpatory evidence regarding the on-boarding of thenew customer and the start of use of the new key-pair. • Evidence of geolocation of wallet : Depending on the typeof trusted hardware used in the wallet, VASPs may beable to obtain evidence regarding the geolocation of awallet device, and therefore evidence regarding the geolo-cation of the hardware-bound keys in the wallet. This mayprovide a means for VASPs to enforce geolocation-relatedpolicies for customers to ensure that the VASPs customersare operating within the permissible jurisdiction (e.g. cus-tomer wallet must be in-country to sign transactions). Forexample, the work of [68] includes the ability to reportlocation coordinates (latitude, longitude and altitude) ofthe attester device. • Key usage sequence : VASPs can also make use of anumber built-in features of some trusted hardware viathe application software (e.g. mobile app) on the wallet.For example, the application can use the underlyingtrusted hardware to maintain a sequential history of theobjects (transactions) signed using the private key insidethe trusted hardware (e.g. in the TPM using the hash-extend operation with the PCR registers and monotoniccounter [5], [21]). This feature allows the VASP toperform an accurate accounting as to which order trans-actions were signed by the wallet system, as compared tothe order in which the transactions were processed (i.e.confirmed) on the blockchain. • Evidence of wallet system configurations : Device attes-tations may permit a VASP to obtain visibility into thedevice component compositions and configurations. Thismay be useful information with regards to the diver-sity [39], [69], [70] of wallet configurations, somethingcrucial from the perspective of malware aimed at walletsystems. This has the advantage of allowing the VASPto advise (or require) customers to replace a weak walletsystem with a stronger system.6X. C
ONCLUSIONS
VASPs today face a number of challenges, ranging fromregulatory compliance related to virtual assets, to potentialcompetition arising from the traditional banking sector.The vision of Chaumian eCash and of Nakamoto’s Bitcoinis that of a peer-to-peer electronic cash based on decentralizedcontrol. Contrary to the current dominance of the centralizedexchange (CEX) model with hosted wallets, this vision pointsto the need for end-users to hold and control their privatekeys. This, in turn, points to the requirement that the end-user’s wallet system incorporate trusted hardware to protectthe private keys.However, trusted hardware alone is not enough. There mustbe an attestation infrastructure – implementing standardizedmechanisms and trust protocols – that supports the wallet intruthfully reporting its internal system state, including the stateof its trusted hardware and the presence of certain types ofkeys in the trusted hardware. This feature is relevant to legit-imate third-party entities – such as asset insurance providersand auditors of CBDC wallets – who require some degree ofvisibility into state of the wallet, but without disclosure of theprivate keys in the wallet.VASPs are best positioned today to provide neutral attesta-tion verification services for the different types of use-casesrelated to wallets. These attestation related services should bepart of a more comprehensive managed compliance servicesoffered by VASPs more generally.A
CKNOWLEDGEMENT
We thank Sandy Pentland and Alex Lipton (MIT) forsupport in this work. We especially thank the various membersof the Trusted Computing Group (TCG) – notably members ofthe Infrastructure Working Group and the Attestations Work-ing Group – who over the past 20 years have worked tirelesslyto define and standardize trusted computing technologies.R
TrustedComputing Platforms: TCPA Technology in Context
Communications of the ACM
Forbes \ cryptocurrency-custody/?sh=386fba3d5479[13] N. De, “Banks in US Can Now Offer CryptoCustody Services, Regulator Says,” Coindesk
New York Law Journal
FinextraNews
Forbes
Trusted Computing Platforms:TPM2.0 in Context . New York: Springer, 2014.[23] F. McKeen, I. Alexandrovich, I. Anati, D. Caspi, S. Johnson,R. Leslie-Hurd, and C. Rozas, “Intel Software Guard Extensions(Intel SGX) Support for Dynamic Memory Management Inside anEnclave,” in
Proc. Workshop on Hardware and Architectural Sup-port for Security and Privacy (HASP) 2016 , Seoul, June 2016,http://caslab.csl.yale.edu/workshops/hasp2016/program.html.[24] F. Mckeen, I. Alexandrovich, A. Berenzon, C. Rozas,H. Shafi, V. Shanbhogue, and U. Savagaonkar, “InnovativeInstructions and Software Model for Isolated Execution,” in
Proc. Second Workshop on Hardware and Architectural Support or Security and Privacy HASP2013 , Tel-Aviv, June 2013,https://sites.google.com/site/haspworkshop2013/workshop-program.[25] ARM, “ARM Security Technology: Building a Secure Systemusing TrustZone Technology,” ARM Limited, ARM TechnicalDocumentation – PRD29-GENC-009492C, April 2009. [Online].Available: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.prd29-genc-009492c/CABGFFIC.html[26] G. Coker, J. Guttman, P. Loscocco, A. Herzog, J. Millen, B. O?Hanlon,J. Ramsdell, J. S. Ariel Segall, and B. Sniffen, “Principles of RemoteAttestation,” International Journal of Information Security , vol. 10,pp. 63–81, April 2011. [Online]. Available: https://doi.org/10.1007/s10207-011-0124-7[27] S. Berger, R. Caceres, K. A. Goldman, R. Perez, R. Sailer, and L. vanDoorn, “vTPM: Virtualizing the Trusted Platform Module,” in
Security?06: 15th USENIX Security Symposium , Vancouver, Canada, July-Aug2006, available on \ storage-technology-for-banks/[32] S. Matetic, K. W¨ust, M. Schneider, K. Kostiainen, G. Karame,and S. Capkun, “BITE: Bitcoin Lightweight Client Privacy UsingTrusted Execution,” in Proceedings of the 28th USENIX Conferenceon Security Symposium (SEC’19) . Santa Clara, CA, USA: USENIXAssociation, December 2019, pp. 783–800. [Online]. Available:https://dl.acm.org/doi/10.5555/3361338.3361393[33] C. Gerber, “Army requires security hardware for all PCs:Coming mandate specifies that new computers contain astandard Trusted Platform Module,”
Federal Computer Week
PC World \ ∼ /media/finma/dokumente/dokumentencenter/myfinma/4dokumentation/finma-aufsichtsmitteilungen/20190826-finma-aufsichtsmitteilung-02-2019.pdf [42] Trusted Computing Group, “TCG Glossary,” Trusted ComputingGroup, TCG Published Specification – Version 1.1 Revision 1.0,May 2017. [Online]. Available: https://trustedcomputinggroup.org/wp-content/uploads/TCG-Glossary-V1.1-Rev-1.0.pdf[43] N. Smith (ed), “TCG Attestation Framework,” Trusted ComputingGroup, TCG Draft Specification – Version 1.0, November 2020.[44] E. Barker, “Recommendation for Key management (Part 1),” NationalInstitute of Standards and Technology, NIST Special Publication SP 800-57, Part 1, Rev 4, January 2016, http://dx.doi.org/10.6028/NIST.SP.800-57pt1r4.[45] E. Barker, M. Smid, and D. Branstad, “A Profile for U.S. FederalCryptographic Key Management Systems,” National Institute of Stan-dards and Technology, NIST Special Publication 800-152, October 2015,http://dx.doi.org/10.6028/NIST.SP.800-152.[46] A. Regenscheid, “Platform Firmware Resiliency Guidelines,” NationalInstitute of Standards and Technology, NIST Publication SP 800-193,May 2018. [Online]. Available: https://csrc.nist.gov/publications/detail/sp/800-193/final[47] A. John, “Cryptocurrency industry faces insurance hurdle tomainstream ambitions,” Reuters \ mainstream-ambitions-idUSKCN1OJ0BU[48] O. Kharif, B. Louis, J. Edde, and K. Chiglinsky, “Interest inCrypto Insurance Grows, Despite High Premiums, Broad Exclusions,” Insurance Journal
PC World
Blockchain and Distributed Ledgers: Math-ematics, Technology and Economics . World Scientific Publishing,Singapore, 2021.[52] A. Lipton, “Stablecoins Are the Bridge FromCentral Banks to Consumer Payments,”
CoinDesk
Building theNew Economy /csrc.nist.gov/CSRC/media/Projects/Supply-Chain-Risk-Management/documents/ssca/2017-winter/TuePM1 3 %20Intel.pdf[60] T. Dodson and E. Cabre, “Blockchain Augmentation ofthe Trusted Supply Chain,” Intel Corporation, RSA2019Conference, March 2019. [Online]. Available: https://published-prd.lanyonevents.com/published/rsaus19/sessionsFiles/13424/PDAC-F02-Blockchain-Augmentation-of-the-Trusted-Supply-Chain.pdf[61] D. Benton, “NSA, Trusted Computing Group andIntel collaborate to standardize supply chain riskmanagement,” Supply Chain Digital \ supply-chain-risk[62] C. Nissen, J. Gronager, R. Metzger, and H. Rishikof, “Deliver Un-compromised: A Strategy for Supply Chain Security and Resiliencein Response to the Changing Character of War,” MITRE Corporation,Report, August 2018.[63] J. Robertson and M. Riley, “The Big Hack: HowChina Used a Tiny Chip to Infiltrate U.S. Companies,” Bloomberg Businessweek \ Journal of Cloud Computing: Advances, Systems and Applica-tions , February 2013.[68] G. Mandyam, L. Lundblade, M. Ballesteros, and J. O’Donoghue, “TheEntity Attestation Token (EAT),” IETF, Internet-Draft draft-ietf-rats-eat-03, February 2020. [Online]. Available: https://datatracker.ietf.org/doc/draft-ietf-rats-eat/[69] T. Hardjono and N. Smith, “Decentralized Trusted Computing Base forBlockchain Infrastructure Security,”
Frontiers Journal - Special Issueon Finance, Money & Blockchains , vol. 2, December 2019. [Online].Available: https://doi.org/10.3389/fbloc.2019.00024[70] T. Hardjono, “Blockchain Gateways, Bridges and Delegated Hash-Locks,” February 2021. [Online]. Available: https://arxiv.org/abs/2102.03933, vol. 2, December 2019. [Online].Available: https://doi.org/10.3389/fbloc.2019.00024[70] T. Hardjono, “Blockchain Gateways, Bridges and Delegated Hash-Locks,” February 2021. [Online]. Available: https://arxiv.org/abs/2102.03933