REPUTATION, TRANSACTIONS AND BLOCKCHAIN

DAVID W. KRAVITZ, PH.D., VICE PRESIDENT – CRYPTO SYSTEMS RESEARCHDAVID.KRAVITZ@DARKMATTER.AE

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

QUESTIONS?

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