Secure Sharing of Design Information with Blockchains

© Hitachi, Ltd. 2018. All rights reserved.
Secure Sharing of Design Information
with Blockchains
2018年電子情報通信学会ソサイエティ大会
BS-7. Network and Service Design, Control and Management
September 13th, 2018
Wohlgemuth Sven* 株式会社日立製作所
梅澤克之湘南工科大学
寶木和夫産業技術総合研究所
*His contribution in this paper is done when he belonged to Albert-Ludwig University Freiburg, Germany
and other organizations before he joined Hitachi, Ltd. in February 2017.

Now: Search with HCI
2
Personal attributes
Pseudonyms,
biometrics, contact
details, credit card,
interests, friends,
medical history,
belongings, and so on
including vulnerability
and incident reports
Share subset
(e.g. vulnerability/incident report)
Search engine
AI-capable machine
• Efficiency: Scalable
computing power
and memory (e.g.
Cloud Computing)
• Effectiveness:
Optimization and
completeness of
problem solving
Problem:
Who is defender or
attacker?

© Hitachi, Ltd. 2018. All rights reserved. 3
Threat analysis
result of analysis
target system
Vulnerability
case 1
Safety & Security Threat
Analysis
Designer
External Vulnerability
Database
Common attack
pattern type and
classification
共通脆弱性識別番号DB共通脆弱性識別番号DB
Functional
requirement
analysis diagram
System
configuration
Design info of
analysis target
system
Vulnerability model
information
Vulnerability
case 2
Vulnerability
case 3
On the basis of the
case database,
vulnerability
information modeled
using meta info such
as threat content and
occurrence condition
(1) Enter the design information of the
analysis target system and set the
attack target
(2) The system refers to the
vulnerability model information and
performs semiautomatic threat
analysis
Search
vulnerability
candidates
that match
the analysis
target system
FT top event
Pre-created
Pre-registration
Interactive
analysis
Other design
information
Macro AT
Component
database
Component
information
Attack Case
Attack success
case and attack
report
Vulnerability
case 3
Vulnerability
case 1
Common
vulnerability type
list
Common vulnerability
identification number
list
But: Threat Analysis needs Information

Natural disasters cause severe disruptions on
Just-In-Time production
(2011 Great East Japan Earthquake on Toyota,
Apple, …; 2016 Kumamoto on Toyota, Sony,
Honda, …)
https://www.bbc.com/news/business-36069349
Non-availability of information in IoT caused by
ransomware (WannaCry) on MS Windows
http://monoist.atmarkit.co.jp/mn/articles/1807/04/news042.html
Information leakage of 140 million identities
caused by vulnerability in Open Source
Apache Struts but no reaction (Equifax) on
security report
https://www.scmagazine.com/equifax-twice-missed-finding-
apache-struts-vulnerability-allowing-breach-to-
happen/article/697693/
and more vulnerabilities …
Integrity uncertain due to technological
development which turns mathematical hard
problems in solvable ones
https://www.zdnet.com/article/ibm-warns-of-instant-breaking-of-
encryption-by-quantum-computers-move-your-data-today/
Example: Supply Chains and Disruptions

Agenda
I. Challenge: Accountability
• Reliable cryptographic key exchange
• Reliable reporting for reducing vulnerabilities
II. Our Way: SK4SDI – Secure Kernel 4
Security Design Information
• Miners in competition for anonymized certification
• Open Data on compliance to smart contracts
III. Unity in Diversity
• Usable HCI with AI as intelligence amplifier
• Digital marketplace on compliance
5

Trusted Computing Base
(TCB) / Kernel
Object
Security
policy
Reference monitor
Audit
trail
Subject
Access request
to d, d* d, d*
Grant access
or deny
access
Enforcement of IT security protection goals (CIA): Security by Design
Search engine
Request:
Search for d, d*
Input:
Design information d
Output:
Design information d, d*
Aggregation &
inference: d, d*
Output:
Vulnerability/incident report
6
Man in the
middle attack

Accountability: Digital Signature
7
Premise: IT security should depend only on access to secret cryptographic key
Digital signature for integrity and non-repudiation of a message
Depends on trapdoor functions: (1) Hash function, (2) hard mathematical problem, and
(3) authentic exchange of cryptographic public key for verification
Security
policy
Reference monitor
(signature verification)
Audit
trail
Subject
Access request, sign(access request, sksubject)
(pksubject, sksubject)
Certification
authority (CA)
(pkCA, skCA), credentials,
revocation
Man in the
middle attack
Check certification
path of pksubject
Or access to (pksubject, sksubject)
Shows (pk*
subject, sk*
subject) → Subject
Success, if data breach in
certification path:
Certification
policy
Show pksubject
→ sksubject

Certification Path (1/2)
8
CA
(pkCA, skCA), credentials,
revocation
Personal attributes
Pseudonyms, biometrics, (skAlice,
pkAlice), …, and so on
Including vulnerability and
incident reports
Certification of relationship
pkAlice → Personal attributes of Alice
Name:
Serial number:
Issued by:
Issue date:
Expiration:
Public key:
Attributes:
Alice
12345678
CA
07/01/2018
07/01/2020
X a # 6 @
Usage
Limits (rights...)
Certificate
Name:
Serial number:
Issued by:
Issue date:
Expiration:
Public key:
Attributes:
S-Trust
08154711
CA
07/01/2017
07/01/2019
K 8 8 @ 39
Usage
Limits (rights...)
Certificate
Vulnerabilities for data breach in
a) Security model
b) Implementation
c) Use of implementation
d) Control of basic secret

Certification Path (2/2)
9
Model checking of type-safe
access control policy
Open source with security
testing and vulnerability
database
Monitoring with audit trail
and anonymization
Hard mathematical problem
Security model
Implementation
Use of security
control
Control of basic
secret
Requirement
analysis
Decidable formalization
Security Engineering Assumption / procedure Data Breach: Vulnerability
Optimal anonymization is
a NP hard problem
Centralized control with
restrictions
Bug
Spoofing, phishing. malconfiguration, …
Progress in search algorithms

Data Breach Detection (IDS)
10
Policy languages: OSL, Ponder, ExPDT, EPAL, XACMLSecurity model
Implementation
Use of security
control
Control of basic
secret
Requirement
analysis
Security Engineering
Observable obligations on reporting
Hysteresis Digital Signature
Audit
Security
policy
Reference monitor
Audit
intelligence
Audit
trail
Audit
trail
Search engine/
CA
Audit
trail
incident compliant

IDS and Audit Trail
11
Attack signature detection
(Rule-based detection)
Anomaly detection
Required
knowledge
Knowledge about all potential
attacks
Complete knowledge about behavior
of system/users
Required
configuration
Continuous update of attack
rules database with authentic
attack rules
Determine normal behavior
(compliance to policy):
• Collecting authentic data
• Data analytics with error rate
(false positives)
• Continuous update of database
Audit intelligence: Required information and configuration
Aggregation of secure audit trails is threatened by inevitable vulnerable identities:
1. Information sharing not perfect against data breach
(database without sharing can be)
2. No consensus on information with vulnerable identities

Byzantine Consensus (Fault Tolerance)
12
Charlie
Alice Bob
0
0
0 0
0
0
Charlie
Alice Bob
0
0
1 0
1
1
0 or 1? 0 or 1?
Without cryptography Digital signature Bitcoin hash chain
• Tolerates 𝑡 <
𝑛
3
failed identities
• No consensus for sharing
security design information
• Tolerates 𝑡 < 𝑛 failed
identities
• Assumes authentic and
consistent cryptographic key
exchange
• Tolerates 𝑡 < 𝑛 failed
identities
• Byzantine consensus by
competitive incentive and
public ledger
• No authentication
➔ Secure information sharing is a matter of trust (with competition)
Objective: Majority agrees on information (consensus)

Agenda
• Reliable cryptographic key exchange
• Reliable reporting for reducing vulnerabilities
II. Our Way: SK4SDI – Secure Kernel 4
Security Design Information
• Miners in competition for anonymized certification
• Open Data on compliance to smart contracts
• Usable HCI with AI as intelligence amplifier
• Digital marketplace on compliance
13

Bitcoin-like blockchains
14
II. Our Way: SK4SDI – Secure Kernel
Request:
Search for d, d*
Input:
Design information d
Trust → Enforcement of rules (policy) on information sharing  Compliance
Miners
…
Ledger
Audit trail
Output:
Compliance report on
authentication of d, d*
Output:
Compliance report on
authentication of d, d*
Auditors
Personal attributes
Pseudonyms, biometrics,
(skAlice, pkAlice), …, and so on
including vulnerability and
incident reports
Personal attributes
Pseudonyms, biometrics,
(skBob, pkBob), …, and so on
including vulnerability and
incident reports
d, d*
Policy
d, d*
Policy
d, d*
Access
d, d*
Certifi
cate
Aggregation of
provenance
SK4SDI
by competitive incentive and
keyed hash chain

Personal attributes
Pseudonyms,
biometrics, contact
details, credit card,
interests, friends,
medical history,
belongings, and so on
including security
vulnerabilities and
incidents
IDA
Context of
master ID
1 ledger Liveness logID ledger
ZKP guarantees
anonymity
Attempt to estimate
additional attribute
values
subset
Direct communication
Multiple
derived IDs
Unique
name/ledger
Authentication:
Compliance log
Trading partner, 3rd party
Discovery of
security design
information in
marketplace
a ＜ attribute
value (e.g. WebKit
version) ＜ b
search market
Exist?
Negotiate
smart
contract
on use
Y
N
Our Way: Secure Search for Usable HCI

Proof of Inequality
16
ProofInequality*: ZKP that a certain attribute value m is m > mr is given as follows：
Δ＝m-mr-1、a=1
Calculate u1, u2, u3, u4 such that
Let
Not limited to m > mr, the SPK can be configured similarly for another inequality.
Then
(Non-interactive)
ZKP
Parts of issuer’s public
key for CL signatures
Operator: ≡≻
* IBM Research Zurich Security Team, Specification of the identity mixer cryptographic library, version 2.3.40,
Technical Report, IBM Research, Zurich, 2013.

Proof on Accountability for Compliance
17
Proof on accountability: Secondary use of personal credentials on AAA
Authentication
Authorization
Accounting
Genesis
Blinded*
pkroot
Policy
on use
pkroot
Access
on use
pkroot
Self-signed
cert(pkroot)
Anonymous credentials
with Hysteresis Digital
Signature as Open
Data
Proof of Inequality for
search on compliance
to a policy for
information sharing
Anonymous digital
evidence relates to
privacy as
informational self-
determination
* verifiable encryption with pk_OA of Auditor OA
Genesis
Genesis
Block 1
Block 1
Block 1

18
Now: Audit Intelligence for HCI
• Reporting on vulnerabilities and incidents
• But: Inevitable vulnerable identities
In the future: With SK4SDI for Usable HCI
• Reporting on enforcement of security policies
• Vulnerable identities compete on compliance
Expected effects: (1) Continuous improvement of security (PKI) with vulnerable identities
(2) Secure Delegation of Rights on using Design Information provides
digital marketplace on privacy with price discrimination
Sustainable knowledge society

Related Work in Standardization
19
ISO/IEC
• N2768 NB proposal SP Connected devices – Proposal by US NB for a study period on
Security and Privacy Baseline Controls for Connected Devices, ISO/IEC JTC 1/SC 27/WG
4, 2018.
• WD(TR) 23187: Cloud computing – Interacting with cloud service partners (CSNs), ISO/IEC
JTC 1/SC 27/WG 5, 2018.
• ISO/NP TR 23246 WD(TR): Blockchain and distributed ledger technologies – Overview of
identity, ISO/TC 307, 2018.
• 27031: Cybersecurity – Information and communication technology readiness for business
continuity, ISO/IEC JTC 1/SC 27/ WG 4, 2018.
• WD 27035-3.2: Security techniques – Part 3: Guidelines for incident response operations,
ISO/IEC JTC 1/ SC 27/ WG4, 2018.
• DIS 3011 – Information technology – Security techniques – Vulnerability handling processes
• WG 11 Smart City White Paper v0.4, ISO/IEC JTC 1/SC 27, 2018.
Internet Engineering Task Force (IETF)
• Google. Certificate Transparency, RfC 6962, IETF, 2013.
• Google, Comodo CA. Certificate Transparency Version 2.0, draft-ietf-trans-rfc6962-bis-28,
2018.
• S. Kent. Attack and Threat Model for Certificate Transparency, draft-ietf-trans-threat-
analysis-15, 2018.

Acknowledgement / 感謝の表明
20
We thank Mishina Yusuke (三科雄介さん) for his comments.
This work was supported by Council for Science, Technology
and Innovation (CTSI), Cross-ministerial Strategic Innovation
Promotion Program (SIP), and “Cyber Security for Critical
Infrastructure” (funding agency: NEDO).
ありがとうございました。
sven.wohlgemuth.kd@hitachi.com

Byzantine Consensus (Fault Tolerance)
25
Objective: Majority agrees on information (consensus)
Charlie
Alice Bob
0
0
0 0
0
0
1
0
0 0
1
0
Perfect sharing
Charlie
Alice Bob
Charlie
Alice Bob
If one identity
fails
0 or 1?
0 or 1?
0
0
1 0
1
10 or 1? 0 or 1?

Data controller
OC terminal
Auditor OA
terminal
Data processor
OH terminal
Data processor
OP terminal
3) Get pk_OA for CS encryption of signature record
on cred issuance (authorization)
1) Request authorization for dS of OS from OC: context_(OC,OH);
show cred_OH on type-safety *
2) Certify authorization for OH : issue cred_(OC,OH) on nym_OH
Open Data
ledger
4) Update signature record for authorization
M_OH = nym_OH‖enc_OA(context_(OC,OH)‖{mj,k, k∈def}),
Bj=H(Bj-1‖M_OH),
S_(OC,OH) = sign_OC(Bj)
5) Generate ZKP values SPK for CL encryption of signature record by pk_OA
6) Propose (M_OH,Bj,S_(OC,OH)) and SPK
for new block
7) Check as miner (M_OH,Bj,S_(OC,OH)) and SPK;
add to new block
Protocol: Authorization
26* OS refers to the data subject, e.g., Alice or Bob, in accordance to the context

Data controller
OC terminal
Auditor OA
terminal
Data processor
OH terminal
Data processor
OP terminal
Open Data
ledger
1) Request dS of Os with cred_(OCOH): context_(OH,OP)
2) Request cred_OH on type-safety
3) Show cred_OH on type-safety
4) Check validity of cred_OH and cred_(OCOH)
with (M_OH,Bj,S_(CA,OH)) and SPK of CA;
(M_OH,Bj,S_(OC,OH)) and SPK of OC
5) Get pk_OA for CS encryption of signature
record on data provenance
6) Generate data provenance for d from OP to OH
M_(OP,OH) = H(dS) || nym_OP || nym_OH‖
Bj=H(Bj-1 || M_(OP,OH)
S_(OP,OH) = sign_OP(Bj)
Generate ZKP values SPK for CS encryption
of signature record by pk_OA
7) Propose (M_OH,Bj,S_(OC,OH)) and SPK
for new block8) Check as miner (M_(OP,OH),Bj,S_(OP,OH)) and
SPK; add to new block
9) dS of OS
Protocol: Accounting
27* OS refers to the data subject, e.g., Alice or Bob, in accordance to the context

Challenges for Security
28
CA
A) Safety: Security policy for data sharing with 3rd party
C) Complexity-theoretical problems become easy to solve
Policy
Enforcement
Trust anchor
No proof on data breach (identity theft) in advance
Universal break of cryptographic system
Identity theft happens
B) Reliable broadcast of
personal data

Challenges and SK4SDI
29
Auditor (CA)
A) Safety: Security policy for data sharing with 3rd party
B) Reliable broadcast of
personal data
C) Complexity-theoretical problems become easy to solve
Policy
Enforcement
Trust anchor
Obligations enable proof on compliance (secure identity)
Biometrics/PUF with blinded Hysteresis Signature
Blockchains for identity
management with secure
delegation of rights provide
Ground Truth

Secure Sharing of Design Information with Blockchains

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Secure Sharing of Design Information with Blockchains

Similar to Secure Sharing of Design Information with Blockchains (20)

More from Sven Wohlgemuth

More from Sven Wohlgemuth (20)

Recently uploaded

Recently uploaded (20)

Secure Sharing of Design Information with Blockchains