REPUTATION, TRANSACTIONS AND BLOCKCHAIN
DAVID W. KRAVITZ, PH.D., VICE PRESIDENT – CRYPTO SYSTEMS [email protected]
IEEE GLOBAL IOT SUMMIT – RABAT, MOROCCO 03 NOVEMBER 2017
ACCESS-CONTROLLED IOT AND HUMAN INTERACTIVITY
• Fortune.com: email from Vint Cerf, Chief Internet Evangelist at Google (coauthor of TCP/IP)
“It has become a kind of magic pixie dust for some proponents.” Still, even Cerf sees potential
in blockchains, where “the parties involved in the system are known and can be evaluated for
reliability and trustworthiness.”
• GDPR: right to be forgotten; offloading access to sensitive assets
• Coindesk.com: Will Provenance Be the Blockchain's Break Out Use Case in 2016?
• Full nodes, pruning, and light nodes: IoT gateways; queries by resource-constrained nodes
BLOCKCHAIN: MINING FOR GOLD- OR PIXIE- DUST?
“Even in the case where isolation boundaries are well-defined, complete, and sufficient to
protect a system or component against compromise, interacting IoT systems might require
well-defined ways of adjusting this isolation to access parts of another system (for example, in
the case of a smart cities subsystem compensating for another during a natural disaster). The
decision process governing this adjustment of the isolation boundary needs to be able to
gauge the context of the situation and the trustworthiness of the entities being considered for
inclusion inside the boundary.”
ISOLATION BOUNDARY – CONTEXT – GETTING TO KNOW YOU
Major underpinning of IOTA: Transaction submitters
actively distribute to consensus by validating transactions
– “We truly believe that permissionless innovation is going
to be the key component of distributed ledgers.”
“A transaction in IOTA can contain two things…Either it
can contain value…and the 2nd component is all about data
security.” “IOTA is the perfect protocol when it comes to
data security.”
“The main reason why IOTA is really, really awesome is
because we have no transaction fees.”
“…protocol doesn’t really care what type of data is
transferred.”
“What I’m really worried about is how do we go away from
permissioned ecosystem towards this whole
permissionless ecosystem.”
“… and the beauty of IOTA is -- because it is so
lightweight -- it can all work in the browser.”
CARING MORE THAN ONE IOTA
• Dominik Schiener, Co-founder of IOTA Foundation:
17 October 2017
• Bitcoin supplies partial 1st “A” of the three “A”s
• Data integrity without entity Authentication
– a great fit for ransomware payments
• Towards “AA”: Full Authentication does not imply Authorization
• Critical for permissioned blockchains
– application-specific read and write access
policy enforcement
• Towards “AAA”: Managing Accountability
• Real-life application requirements
– private and auditable
IS THE SYSTEM SECURE?:APPLYING THE FULL “BATTERY” OF TESTS
• NIST Special Pub 800-63B Authentication & Lifecycle Management: “The verifier SHALL
NOT store the identifying key itself, but SHALL use a verification method (e.g., an approved
hash function or proof of possession of the identifying key) to uniquely identify the
authenticator.”
• NIST Special Pub 800-63-3 Digital Identity Guidelines: “A digital identity is always
unique in the context of a digital service, but does not necessarily need to uniquely identify
the subject in all contexts. In other words, accessing a digital service may not mean that
the subject’s real-life identity is known. Identity proofing establishes that a subject is who
they claim to be.”
STANDARDS-BASED WITH A V2V ORIGIN
https://www.its.dot.gov/factsheets/pdf/CV_SCMS.pdf
Behind the scenes:
1. Static: Standard public key certificate Bob’s identity and/or affiliation ǀǀ Bob’s public key; sign fresh assertion
request to Identity Provider (IdP) using Bob’s corresponding private key
2. Dynamic: Standard (keyless) attribute certificate Bob’s attributes ǀǀ Bob’s public key certificate ID; sign fresh
assertion request to Attribute Authority (AA) using Bob’s corresponding private key
Or
Use resource-constrained device mechanism, such as challenge-response physically unclonable functions (PUF)
3. Convert IdP- issued assertions to uniformly-constructed Enrollment Certificates (ECerts)
4. Convert AA- issued assertions to uniformly-constructed Transaction Certificates (TCerts)
Transaction Certificate Bob’s attributes [encrypted*] ǀǀ Bob’s one-time-use public key
[Later: *TXN metadata includes selectively released keys]
TRUSTED TRANSACTIONS REQUIRE TRUSTED PROVENANCE
• Signature TCert- owner:
• key expansion to recover TCert private keys (signature; key agreement)
• selective disclosure keys for TCert attributes proof-of-possession (PoP)
• Key agreement TCert- requestor:
• certain of its PoP keys
• Primary TCA:
• threshold-/multi- signature generation of TemplateTCerts
• Subordinate TCA:
• generation of TCerts (redundant & restricted operations)
• Audit1:
• capability to cluster transactions for subset of TCert owners
• Audit2:
• passively access PoP keys for subclasses of users/devices
• Audit3:
• Pre: payloads via Validator-enforced transaction-creator audit granting
• Post: payloads via key agreement TCerts or authorized queries
MAKING THE BLOCKCHAIN ACCESSIBLE
• Eventual consensus-driven re-hashing of entire transactions into hash-chained blocks using next-generation algorithm
• Integrity of past transactions maintained
• Attempted substitution fails even if original signature scheme and its underlying hash now vulnerable
• Confidentiality of past transaction data maintained even if original key agreement scheme now vulnerable
• If current signature scheme robust and signed query by authorized requester required to access ciphertext
• Such particular data ciphertext stored off-chain and referenced on the blockchain by its hash
• Keeps blockchain reasonably sized
• Consistent with hashing state into transactions
CRYPTO AGILITY AND HASH CHAIN MIGRATION
• Subsets of validated, time-stamped, immutable transactions propagated on blockchain can later be
released by users
• Supplies evidence of whereabouts and behavior that is not spoofable (even by fraudster using
misappropriated PII)
• When and where user’s devices were or weren’t present
• Veracity of devices attested/corroborated/contradicted by neighboring devices/users
• User reputation / device reputation reflected as attributes or as attribute qualifiers: selectively
releasable (publicly, or confidentially to Validators and/or intended transaction recipients)
• Reputation thresholds may be set by use-case- specific policy as enforceable by Validators
– Such reputation thresholds may apply to signature TCerts (transaction creators) and/or key
agreement TCerts (transaction recipients)
NETWORK-EDGE ANOMALY DETECTION ONLY AS GOOD AS TRUSTWORTHINESS OF END-ENTITY USERS AND DEVICES
• Trusted users, trusted devices, users trusted based in-part on use of trusted devices
• Multi-factor authentication:
– devices owned/operated directly by user
– assertions/voting/corroboration by (time- or space-) neighboring devices
– device-based roots of trust, e.g., manufacturer provenance; PUFs: key / random nonce generation, memoryless repeatable-key storage, device authentication, anti-counterfeit
• Client-server splits:
– server-authorized dynamic transformation of client that is differentially detectable from adversarial modification of client: through client responses to server challenges
– server-based dynamically refreshed locking/unlocking of client-local key store modules
• Inviter-Invitee protocol runs: endorsements via attribute certificate chaining incorporated into resultant “communication lines”*; initiate “communication lines” as inspired by positive experience with pair-wise / group-wise blockchain transactions *[TrustCentral.com US patents: 9,716,595; 9,578,035; 9,455,978; 9,356,916; 9,270,663]
• Inviters base choice of invites on current reputation of potential invitees
• Invitees can check current reputation of inviters as condition of acceptance
• Dedicated “communication lines” as prerequisite to entrusting with properly handling sensitive data, and/or believing data (prior to precipitating user action or device reconfiguration/recalibration)
• Performance metrics of established communication lines affect reputation of participating users/devices
IDENTITY AND REPUTATION FEEDBACK LOOPS
• Example: On-chain physician order to activate IV apparatus
• IV apparatus does not wait for and may remain oblivious of payment aspects
• Secure, non-hacked IoT device will not report service fulfillment ahead of actually providing such service (e.g., life-
saving IV drip)
• Payment can be via cryptocurrency or off-chain- reconciled monetary exchange
• Reputation metrics, as incorporated and updated into TCerts, play a vital role in enabling a highly scalable and
responsive concurrent- or post- service-delivery payment reconciliation model
• Reputation of devices; reputation of users
• Device robustness
• Payment timeliness
• Service performance timeliness and accuracy
• Reduce dependency on complex fully-automated, non- fully-vetted/understood “smart contract” code
SCALABLE HYBRID TRANSACTION MODEL
ADD AN INTERNAL ATTRIBUTE CERTIFICATE AUTHORITY (ACA) (1 OF 2)
• The ACA interfaces with internal/external Attribute Authorities (AA) indirectly via a User Agent that
enables the User to acquire verifiably fresh evidence of attribute ownership
• Such evidence gets amalgamated into an encrypted database accessible by a Primary Transaction
Certificate Authority (TCA) for ultimately establishing the legitimacy at Subordinate TCAs of
requests for Transaction Certificates (TCerts) that include specified attributes
• There may be multiple Primary TCAs that serve a given chain, with overlapping or disjoint
coverage areas (such as Affiliations or other attribute types) for which they are trusted by
some subset of relying parties. The ACA may encrypt accordingly, so that a particular Primary
TCA only accesses attribute ownership proofs within its domain
• This is analogous to an internal Registration Authority (RA) that interfaces indirectly with
internal/external Identity Providers (IdP) in order to apprise an Enrollment Certificate Authority (ECA) of
legitimate requests for Enrollment Certificates
ADD AN INTERNAL ATTRIBUTE CERTIFICATE AUTHORITY (ACA) (2 0F 2)
• Use can be made of standardized methods such as mutually authenticated TLS, X.509 self-
signed (User Agent) client certificates, and SAML holder-of-key assertions
• The combined Public Key Infrastructure (PKI) / Privilege Management Infrastructure (PMI)
system may deploy intra-chain, inter-chain, cross-certification, multi-signature, and/or
stealth multi-signature (i.e., threshold signature) elements for efficient decentralization that
preserves interoperability with legacy/external systems in order to inherit/establish and
maintain trust.
• Enables a natural split of Client between User Agent and Signature Service Provider
• hash(Rand) used as an index for TemplateTCerts, where Rand from ACA known only to
legitimate User Agent
• The bootstrapping of identities and attributes through means of PKI and PMI can coexist
with web-of-trust- type attestations. As a degenerate case, static and/or dynamic attributes
are introduced into the blockchain with 0-level assurance/reputation, such that their lives
begin on the blockchain
Device Manufacturer Distributor Consumer i Consumer j
Device Creation (TXN A): payload Device Serial Number(s); metadata Device Manufacturer
signature TCert with “selectively released” attribute(s) key(s) + Device Manufacturer-acquired
Distributor- owned key agreement TCert with Distributor attribute key
First Sale (TXN B): payload specific Device Serial Number and decryption key for payload of
TXN A; metadata Distributor signature TCert with attribute(s) key(s) + Distributor-acquired
Consumer i- owned key agreement TCert with pseudonym attribute key
eBay (TXN C): payload decryption key for payload of TXN B; metadata Consumer i
signature TCert with pseudonym attribute key (with pseudonym matching TXN B) + Consumer
i- acquired Consumer j- owned key agreement TCert with pseudonym attribute key
SUPPLY CHAIN PROVENANCE:TRANSFERRING REPRESENTATIONS OF DEVICE OWNERSHIP
TXN A TXN CTXN B
• APPLICABLE TO AD HOC COLONIES OF DEVICES• Can organize for task fulfillment
• CALLS FOR DEVICE PARTICIPATION VIA BLOCKCHAIN• May specify acceptance criteria: minimum attribute rating scores• Responses by qualified devices are incorporated into blockchain
• DEVICES CAN USE FACTORY-PROVISIONED CERTIFICATES• Prove attributes to ACA via AA-issued assertions
• OFF-CHAIN FULFILLMENT• Response transaction TCerts usable for TLS authentication
• ON-CHAIN MUTUAL RATING OF DEVICES• Reference rated device’s TCert• Ratings encrypted for access by Analytics Processor (AP)• AP clusters individual ratings according to deviceID• AP acting as AA issues (cumulative) attribute rating assertions
•EXTENSIBLE TO H2M • Device matches?: (a) presence at establishment/service use, and(b) user’s rating of it when-/where- ever• AP clusters TCerts according to owning user, even across multiple devices
• Thwarts Sybil attacks*
AN M2M USE CASE External Attribute Authority (AA)Internal Attribute Certificate Authority (ACA)
*
Bob (Inviter)
Client app with LKSM, DIT
Invitation:• Client app with DIT• E-mail address• Designate attributes• Authentication question• Answer to question• Digitally signed
Customer Facing Domain
Login
HSM LDAPDIT
PendingInvite
DIT(hash)
Key Escrow Domain
AA RA
HSM
CA
Sally (Invitee)
Security Ecosystem
E-mail invitation with one-time use link (or invite #)
Client app with LKSM, DIT
Creates multiple key pairs
DIT = Digital Identity Token Certificates
LKSM = Local Key Store Module
HSM = Hardware Security ModuleAA = Attribute Authority
RA = Registration Authority
CA = Certificate Authority
Bob’s public key previously received and stored by Key Escrow Domain
INVITER-INVITEE PROTOCOL EXAMPLE
• This enables “pre-validation”: eases submitted transaction Validation phase requirements
for IoT-friendly speed up
• Login to Mediating Service Provider to associate Enrollment Certificate with profile.
Mediating Service Provider checks for static identity/identifier match, and can require proof
of possession of Enrollment Private Key
• Login to Mediating Service Provider to request AA-issued attribute certificates that each
reference Enrollment Certificate of requester and include one or more pairs of
hash(Enrollment Certificate) and associated Pointer Value (for an attribute certificate
(resulting from Inviter-Invitee protocol run) that indicates requester is eligible to transmit
to owner of that Enrollment Certificate)
LEVERAGING INVITER-INVITEE RESULTS ON BLOCKCHAIN (1 OF 2)
• If Mediating Service Provider‘s AA is recognized by Subordinate TCA, Client can request a batch of key agreement
TCerts owned by the entity that owns one or more of the attributes that the requesting Client identifies (as learned by
the Client through querying the Mediating Service Provider via the Pointer Values)
• Subordinate TCA matches the indicated hash(Enrollment Certificate) of the AA-issued attribute certificate against one or more TemplateTCerts that include hash(Enrollment Certificate) as an index (along with hash(Rand))
• Request can be approved either way, but include a flag visible to key agreement TCert owner that indicates whether or not communication line exists (and indicates that key agreement TCert is not reflexive)
• Key agreement TCerts are not successfully reusable
• Anti-phishing mechanism: Subordinate TCA does not selectively release sensitive attributes of issued TCerts, even if known by non-reflexive key agreement TCert requester, unless flag set because of requester-demonstrated knowledge of static or pseudonymous identity/identifier
– For example: Account number revealed by account holder within a blockchain transaction responsive to a previous blockchain “flagged” transaction (where that previous-transaction creator may have selectively released one or more relevant attributes of the signature TCert)
– Account numbers may be subaccount numbers (to dilute account activity leakage)
•Common ownership of subaccounts is not revealed even if recipients from different subaccounts collude
LEVERAGING INVITER-INVITEE RESULTS ON BLOCKCHAIN (2 OF 2)
Provisioning of IoT device generally done through an installer
(7)
(6) Digital Identity Token (DIT) asserting identity
A controlled device may create & sign DIT which
may include device’s specs and/or claimed
identity/role (e.g., Brake Control Unit) and/or its
public key(s)
(7) DIT Acceptance; Device’s Identity Association
DIT to System Installer who may digitally certify it with
identity assertion. DIT and/or installer certification may
be sent to Security Ecosystem
(8) Authentication
Processed
DIT &/or device identity
may be verified and
typically accepted by
Security Ecosystem;
device may be
registered with newly
created Attribute
Certificate stored with
Attribute Authority
(9) Trusted Public Keys
Security Ecosystem may securely send device public key
certificates of other devices/groups device is to trust (e.g.,
firmware signing authority; automotive maintenance group)
(9)
(9)
Asserted Identity(e.g., Brake Control Unit)
Device board Digital Identity Token
Attribute Authority (AA)
Public Key Infrastructure (PKI), (possibly Privilege Management
Infrastructure PMI)
Security Ecosystem Platform
(8)
FPGA
Installer
A security ecosystem: Provisioning an IoT device
An Automotive Use Case Example using PUF
Inviter-Invitee Protocol (high level)
Attribute Authority (AA)
Public Key Infrastructure (PKI) and Privilege Management
Infrastructure (PMI)
Security Ecosystem Platform
(3)
(10) Inviter and Invitee processing may generate audit trails based, in part, on digital signatures
(1) System Installer user (or an IoT device) may invite an IoT device, (e.g. a Human-Machine Interface) by sending its DIT and/or requesting agreement
(2) Human-Machine Interface may reply, may send its DIT and/or accept agreement
(3) System Installer may provide its certification of device’s agreement, DITs and/or agreements to Security Ecosystem
(4) Security Ecosystem may run verification check; then may accept agreements
(9) Persistent, secure communication line may be established between the parties (i.e., devices/users) typically until terminated
(9)
Installer
A security ecosystem:
Inviting of an IoT deviceAn Automotive Use Case Example
Asserted Identity(e.g., Human-
Machine Interface unit)
(1)
(2)
(5)
(5) Out-of-band confirmation: Security Ecosystem may send a one-time-only unique ID* to Human-Machine Interface IoT device
(6) Human-Machine Interface may send unique ID* to Installer
(6)
(7) System Installer (or device if an IoT device) may certify completion of protocol and/or send it together with unique ID* to Security Ecosystem
(7)
(9)
(3)
* Typically encrypted
(8) Security Ecosystem may review, verify, accept and/or issue Attribute Certificate for Communication Line and its agreement
(8)
The IoT devices within the vehicle
become members of an “IoT Devices
Group”
(1)
(4)
(3)
(2)
Human-Machine Interface Control Unit
Telematics Control Unit
INSTALLER ESTABLISHES SECURE COMMUNICATION LINES BETWEEN IOT DEVICES (ELECTRONIC CONTROL UNITS) IN A VEHICLE
IoT Endpoint
PUF*
•Client App
•Crypto capabilities•Digital Identity Token
DIGITAL AGREEMENT:
•Comm Line Use Rules
•Security rules
•Business Logic
Secure, Authenticated, Persistent Communication Line
* PUF = Physically Unclonable Function (digital “fingerprint”)
IoT Endpoint
PUF*
•Client App
•Crypto capabilities•Digital Identity Token
Communication
LineIoT Endpoint
IoT Endpoint
IoT Endpoint
IoT Endpoint
A “Group” of IoT Devices (e.g., a vehicle)
Anti-Spoofing:No Comm Line,No Certificate,
No Access
Maintenance GroupSupportEndpoint
Authenticated group access
Platform to endpoints
Security Ecosystem Platform
KEY MANAGEMENT
PreK_Root K_TCert Attribute_EncryptionKey[i] Attribute_IntegrityKey[i]
or KeyVersion w/o EnrollmentPublicKey ●●
TCertID i●●
▪▪
Auto, Banking & Construction│
Auto│
Ford│← TCertID
TCertOwner is a particular Ford onboard unit
Inviter Protocol: designed to be “Invitee” phishing-resistant
Inviter’s client to Mediating Service Provider:
• Pointer Value(s) or nicknames or other means for service provider to locate particular attribute
certificates
• DIT_part_1
DIT_part_1 is comprised of DIT_ID, New Pointer Value, Invitee Email Address (and/or other contact
information for intended invitee that is usable by service provider for invitee that is not necessarily
registered with the service provider), and the encryption for access by the service provider’s AA of:
[Rand_1, Rand_2, Rand_3, and a digital signature (generated using an inviter’s signature generation
private key) over DIT_ID, Private_Identifier_1 and New Pointer Value]. New Pointer Value is the Pointer
Value that will be used for the attribute certificate to be generated by the service provider’s AA if the
invitee protocol runs successfully
[Private_Identifier_1 = hash(answer || Rand_1); Private_Identifier_2 = hash(answer || Rand_2), where
New Pointer Value = hash(Private_Identifier_2);
KEK = hash (answer || Rand_3), where KEK is a key encryption key]
EMBODIMENT OF (ASYNCHRONOUS) INVITER PROTOCOL- AND INVITEE PROTOCOL- CRYPTOGRAPHIC MESSAGING AND PROCESSING
Inviter’s client to Mediating Service Provider:
• Data_part_1 (optional)
Data_part_1 is comprised of a digital signature (generated using an inviter’s signature generation private key) over
DIT_ID and Confidential Data and Rand_4, and the encryption for access by the service provider’s AA of: [Confidential
Data and Rand_4]; Rand_4 can be used to hide low-entropy Confidential Data against guessing; Confidential Data may
include sensitive data concerning the intended invitee’s association with the inviter and/or with the inviter’s institution
• DIT_part_2, where the DIT_part_2_data component of DIT_part_2 includes “security question” if a (security question,
answer) pair is used
• Data_part_2 (optional) DIT_part_2 and Data_part_2 are releasable to the purported invitee’s client or browser upon
successful login.
• DIT_part_3 (optional)
• Data_part_3 (optional)
DIT_part_3 and Data_part_3 are releasable to the purported invitee’s client or browser if that service provider subscriber
has passed Test_1
INVITER PROTOCOL, CONTINUED
Inviter’s client to Mediating Service Provider:
• DIT_part_4 (optional)
• Data_part_4 (optional)
DIT_part_4 and Data_part_4 are releasable to the purported invitee’s client or browser if that service
provider subscriber has passed Test_2
For 2 ≤ i ≤ 4, DIT_part_i is comprised of DIT_ID, DIT_part_i_data, hash(Data_part_i), and
DIT_part_i_signature, where DIT_part_i_signature is a digital signature generated over DIT_ID,
DIT_part_i_data and hash(Data_part_i)
INVITER PROTOCOL, CONTINUED
Part of the processing may involve the generation of one or more digital signatures attributable to the
invitee, particularly if non-repudiation relative to acceptance of one or more Digital Agreements is involved
• Service provider transmits to invitee: DIT_part_2 and Data_part_2
• Invitee transmits to service provider: Nonce_Invitee_1 encrypted for access by AA (where
Nonce_Invitee_1 is generated by invitee’s client or browser or peripheral device)
• Service provider transmits to invitee: [Nonce_Invitee_1, Rand_1, and Nonce_AA_1] encrypted for
access by invitee (where Nonce_AA_1 is generated by AA)
• If Nonce_Invitee_1 is correct, invitee transmits to service provider: [Nonce_AA_1, Private_Identifier_1
= hash(answer || Rand_1), and Nonce_Invitee_2] encrypted for access by AA, where “security
question” is found within DIT_part_2
• If Nonce_AA_1 is correct and the previously received digital signature over DIT_ID,
Private_Identifier_1 and New Pointer Value (from DIT_part_1) verifies correctly using
Private_Identifier_1 from invitee, then service provider transmits to invitee: [Nonce_Invitee_2,
Rand_2, and Nonce_AA_2] encrypted for access by invitee
INVITEE PROTOCOL
• AA may (preferably securely) now or later archive [DIT_ID, Private_Identifier_1, New Pointer Value,
and digital signature over DIT_ID, Private_Identifier_1 and New Pointer Value] as part of the
information relating to the invite that may be subject to possible audit; service provider may also
transmit to invitee: DIT_part_3 and Data_part_3 (if available), since the invitee has passed/satisfied
Test_1
• If Nonce_Invitee_2 is correct, invitee transmits to service provider: [Nonce_AA_2, Private_Identifier_2
= hash(answer || Rand_2), and Nonce_Invitee_3] encrypted for access by AA
• If Nonce_AA_2 is correct and if hash(Private_Identifier_2) computed over Private_Identifier_2 from
invitee matches New Pointer Value from DIT_part_1 in invite, then service provider transmits to
invitee: [Nonce_Invitee_3, Rand_3, and New Pointer Value] encrypted for access by invitee; AA may
now or later generate an attribute certificate to be owned by the invitee, and which includes
Private_Identifier_2 as one of its fields; Service provider may also transmit to invitee: DIT_part_4 and
Data_part_4 (if available), since the invitee has passed/satisfied Test_2. If Nonce_Invitee_3 is correct,
then Rand_3 may be used at invitee’s client or browser and/or peripheral device to derive KEK as hash
(answer || Rand_3), where KEK is a key encryption key used originally by inviter
INVITEE PROTOCOL, CONTINUED