A Comparison of Trust Models Marc Sel Director Pwc Agenda
Total Page:16
File Type:pdf, Size:1020Kb
A Comparison of Trust Models Marc Sel Director PwC Agenda • Introduction • Trust • Overview of selected trust models • ICAO PKD (PKI Directory) • EU LOTL (List of Trusted Lists) • US FICAM (Federal Identity, Credential, and Access Management) • POW models (Proof Of Work) • Comparison • Appendix • Abbreviations • Further references 2 Introduction • Scope of this presentation: application level trust models • This encompasses components in different categories: • Computational trust • Technical/operational trust • Legal/regulatory • Trust model typically combines components from these categories • For this presentation the ‘rest of the service stack’, i.e. hardware, OS, etc. are excluded 3 Trust “Trust (or, symmetrically, distrust) is a particular level of the subjective probability with which an agent assesses that another agent or group of agents will perform a particular action, both before he can monitor such action (or independently of his capacity ever to be able to monitor it) and in a context in which it affects his own action. When we say we trust someone or that someone is trustworthy, we implicitly mean that the probability that he will perform an action that is beneficial or at least not detrimental to us is high enough for us to consider engaging in some form of cooperation with him.” Source: Diego Gambetta. Trust: Making and breaking cooperative relations - can we trust trust? 1988. 4 Trust model 1: ICAO PKD Established in 2007 to support global interoperability of ePassport validation to act as a central broker to manage the exchange of certificates and certificate revocation lists. ICAO Council created PKD MOU ICAO PKD Board ICAO PKD ICAO Members Governance PKD Board Rules of Procedure Operation Procedure to Determine the PKD Board Composition Replacement of PKD Board Members Procedure for Handling Operational Complaints Procedure for MOU Amendments Procedure for PKD Fee Schedule Procedures for the ICAO PKD Regulations for the ICAO PKD Netrust (SG) 5 Trust model 1: ICAO PKD ICAO scheme for chip integrity through PA Issuing State A Relying State B CS Certificates CSCA CS revocation Signs IS DSCA [BAC] certificate ICAO PKD PA Verifies SAC SOD DS Certificates Issuing Authority [AA] DS CRL [EAC] DSCA May optionally contain DS certificate ISO/IEC 14443 ISO/IEC 7816-4 Signs SOD eMRTD from Issuing State A 6 Trust model 2: EU LOTL EA EU LOTL List of Trusted National Lists Accreditation Body Trust Lists per Member State Accredits Conformity Supervisory Assessment Body (SB) Body (CAB) Report Assess Supervises TSP 7 Trust model 3: US FICAM 8 Trust Model 3 - US FICAM WHAT - Federal Identity, Credential, and Access Management (FICAM) Program tasked with aligning the Identity Management activities of the US Government. FICAM’s focus is to assure the security and privacy of Government to Citizen (G2C), Government to Business (G2B) and Government to Government (G2G) digital interactions and services. WHY - HSPD-12 - Information Sharing Environment ISE - Need for Federal HOW • Federal CIO Council established an ICAM Subcommittee, and a ICAM Segmented Architecture was established as per the Federal Enterprise Architecture (FEA), in a 5 layer Segmented Architecture (Performance, Business, Technology, Services, Data) • General Services Administration (GSA) operates FICAM testing program with oversight from the Office of Management and Budget (OMB) • Concept of Trust Framework Providers (TFP) • The TFPAP defines a process whereby the government can assess the efficacy of the Trust Frameworks for federal purposes so that an Agency service can trust an electronic identity credential provided to it at a known Level of Assurance (LOA) • LOAs originate from OMB Memorandum M-04-04, E-Authentication Guidance for Federal agencies, 2003, supplemented by NIST SP 800-63-2 9 @GSA Source: http://www.idmanagement.gov/approved-identity-services Trust Model 4 POW - Bitcoin • The Bitcoin Ecosystem allegedly originated from software developed by Satoshi Nakamoto and released in January 2009 • With regard to cryptography, based on a combination of Elliptic Curve Cryptography, RIPEMD and SHA256 hashing. • Bitcoin Reference Client = ‘full client’ with wallet, miner, blockchain copy and network node • Various versions of ‘partial clients’ are implemented too • The BTC software is now maintained by volunteer open-source community coordinated by four core developers. • As of April 2013, Satoshi Nakamoto was estimated to have obtained 1,814,400 BTC, of which he still owned 1,148,800 BTC. 11 How does Bitcoin work? Core model Reference Client (‘Full node’) Persistent Temporary Wallet Miner Wallet’s new trx Keypair (ECC) Prepare candidate block Miner’s candidate Address RIPEMD/SHA256 Attempt to find nonce Network node Blockchain (full copy) block Propagation Exchange P2P 12 Why Trust Bitcoin? . “Distributed Consensus based on Proof of Work” . Without a central repository or trusted administrator, why should any person accept BTC? BTC is designed to address three challenges to BTC authenticity: 1) Is this BTC really from the payor? – BTC’s include a digital signature with payor identification (similar to those used to authenticate typical Internet transactions) 2) Is the payee receiving a “real” BTC? – BTC’s must contain data meeting certain mathematical rules. The data is easily validated as meeting the rules, but fabricating this data requires immense computing power. 3) Has the payor used the same BTC to pay another payee? – The BTC data contains a history of its use, so payee’s can easily validate that the BTC has not been used multiple times by the same payor. 13 Comparison ICAO PKD eIDAS US FICAM Bitcoin (blockchain) Actor: initiator ICAO Council European Fed CIO Council "Satoshi Commission / (administrative) Nakamoto" European Parliament (legislative) Actor: PKD Board EC/EP OMB P2P model with governor/oversig reference ht implementation Actor: operator Netrust (SG) EC and Member GSA and TFS Individual nodes States program and exchanges Actor: assessors Self-assessment SB, EA and CABs GSA-TFPAP, TFP AAs n/a Actor: subscribers Travellers from ICAO EU Citizens C2G/B2G Anyone members Actor: relying IS of visited countries Primarily PS Fed Agencies Anyone parties 14 Comparison ICAO PKD eIDAS US FICAM Bitcoin (blockchain) Objective Worldwide authenticity Enhance trust in US electronic Identity Worldwide of travel document & electronic plus management of dematerialised bearer transactions (EU eID credentials and money and Trust Services) for access, of NP for (fiduciary) the Internal Market, Federal Gov for Natural and Legal Persons Mechanism MOU EU Regulation FICAM Program Voluntary (mandatory for (ICAM, FPKI, TFS, participation Member States) + ESO HSPD-12, FIPS 201) - M460 "rules for participation" Impacts Participating States EU-based IdPs that US Fed Agencies and Payer/payees want to have their private sector TFPs willing to accept credentials recognised that want to have bitcoins by MS public sector their credentials Relying Parties. TSPs trusted by US Fed that want their Agencies services to have legal effect. 15 Comparison ICAO PKD eIDAS US FICAM Bitcoin (blockchain) Structuring Participation by eMRTD Notification for eID Authority To Offer Mining (finding a principle Authority (EMA) (low, substantial, Services (ATOS) hashvalue that high), discretionary through TFS program meets specific qualification of TS for service delivery to constraints) (electronic, advanced, FedGov qualified) with supervision Conformity Registration procedure MS notification of eID TFS ATOS and TFP n/a mechanism and test bench to EC/MS SB (OIX, Kantara, …) procedure registration in LOTL, assessment MS SB's TL Supporting ISO/X.509 ETSI/CEN M460 ISPPAP, NIST SP 800 Compliance to hw/sw/standards series and FIPS 201 reference (PIV) implementation Regulations PKD Regulations EU 910/2014 + IAs FICAM (supported by Electronic money SP 800-63) - FISMA regulations (supported by SP 800- 53) 16 Comparison ICAO PKD eIDAS US FICAM Bitcoin (blockchain) Machine readable Machine readable error LOTL and TLs TFP metadata Blockchain information codes for non- conformant entries in the PKD Liability ICAO MOU Art 6: ICAO Identity (Art. 11): in X- Identity proofing: Own exempt, participants for border trx, notifying CAB, but TFPAP responsibility. their own MS, issuer, operator limited to technical When using a errors/omissions of the authentication compliance service provider, procedure. Trust some contractual Services (Art. 13): liability may be TSPs provided 17 Conclusion • At cryptographic level, there are no business semantics involved, hence the technical trust model is simple • Application level trust models have been created to solve a particular problem, not a generic one • Defining and comparing such trust models is not simple • In a nutshell: • ICAO PKD distributes certificates on the basis of a MOU • EU eIDAS aims at providing the legal foundation for STORK and at providing legal effect for electronic trust services artefacts • US FICAM offers an identity framework with no legal effect as it is limited to the technical aspect • POW schemes are different, both in their technology and in their (lack of) liability and legal effect 18 Appendix Abbreviations • AAs – Assurance Assessors (US CAB for FICAM) • CAB – Conformity Assessment Body (ISO concept) • EC – European Commission • EP – European Parliament • ESO – European Standard Organisations (CEN/CENELEC/ETSI) • GSA – • IA – Implementing Acts • ICAM – Identity, Credentials and Access Management • ICAO – International Civil Aviation Authority