metrology cloud wp1 · metrological administrator for trust ensurance 5. modular security layer....

Metrology Cloud

WP1

Metrology Cloud Consortium Meeting Year 1

PTB BerlinWP1-Lead: Neumann, Prof. Dr. Nordholz

Dev-Team: Dohlus, Kammeyer, Nischwitz, Wetzlich, Yurchenko

Topics

2

➢ Goals – „Why Metrology Cloud?“

• WP1: Architecture – Desiging a Secure Trust-Network

• WP1: Schema – Data Harmonization

• Introducing:

• MC Consortium Wiki

• MCoaT Demo

• MCoaS

• AuthStick

Project Overview

3

Co-Coordination:

❖ J. Nordholz, 8.55

❖ J. Neumann, 8.52

❖ A. Oppermann, 8.52

❖ D. Peters, 8.54

❖ M. Esche, 8.51

Coordination: F. Thiel

Let‘s talk about people…

4

… how they work …

5

… and how they share data

6

… and how they share data

7

Throwing stakeholders into the mix …

8

… adding in external ressources …

9

… and introducing: the Internet

10

Adding in examplary

labels …

Measuring

Infrastructure

External

Databases

… and finally showing

communication pathways.

This reflects the current state

Switching to Metrology Cloud System …

11

Getting rid of non-uniform

data exchanges …

… build the Metrology Cloud

Net on the set of Nodes …

… and finally show optimized

data flow pathways.

Measuring

Infrastructure

External

DatabasesThis reflects what we aim for

Metrology Cloud Mission Statement

Measuring

Infrastructure

External

Databases

Metrology Cloud Mission Goal

❖ Single-Point-of-Contact: every piece of information is attached to abstracts like the digital represantion of a measuring device or product line

❖ Uniform data structure and interfaces allow for easy and transparent data exchange

❖ Data is shared between stakeholders securely and on the basis of what is minimally needed to satify regulatory demands

Potential Software Update Process

13

1. Update issued

2. Conformity of update

3. Request 4. Ensemble-Test5. Permit

6. Approval

7. Approval

Topics

14

✓ Goals – „Why Metrology Cloud?“

➢ WP1: Architecture – Desiging a Secure Trust-Network

• WP1: Schema – Data Harmonization

• Introducing:

• MC Consortium Wiki

• MCoaT Demo

• MCoaS

• AuthStick

Requirements specification

15

1. Leave control with the data-owner

2. Prevent changes to process-relevant data

3. Fast and secure consensus

4. Metrological administrator for trust ensurance

5. Modular Security Layer

Metrology Cloud Architecture

16

Stakeholder DataOnly process-relevant data is shared

with the MC by copy to the node

Encrypted Databasewith shared schema

Secure Web frontendfor plattform independent access

Immutable Chains (DLT)for logging, access management

and Smart Contract processing

Trusted Metrology Cloud Node

Reference Architecture under

development by

Metrological Administrationvia integrated decentralized hard-

wired contracts and consensus

Architecture Advantages

17

• Technology Open Development

• Using standard web APIs (JSON over https)

• Distributed (Non-centralized) Architecture

• Modern, flexible Security Layer

• Secure, digital Identities for People and Devices

• Verified Smart Process Execution

Contact to the Stakeholder-Architecture

18

Metrology

Cloud

All data to be shared

with the MC can be

pushed to the node

Generating

TrustDatabase / storage

Web services Intranet

Database connector

Remote

infrastructure

External

data sources

Database interface

MC Node Building Blocks

19

DLT

PKI

Log Book

ConMan

BL

DB

M-Admin

Access-M

Web UI

MC Development

20

Frontend

Database

Access Rights Management

Admin-Service

BusinessLogic

MC Software Framework / MC Utils / MC Build Environment

Backend Logging

Inspector

Connection Manager

Public Key Infrastructure

Distributed Ledger Technology

Schema Wiki

Auth Stick

Task for the MC Eco-System

21

Node platform

Testing

Hardware platform

Certification of Smart Contracts

Smart Contracts

Initial configuration and deployment

Data import and export adapter

Existing, proprietary databases

Frontend

a willing institution

respective stakeholder

Topics

22

✓ Goals – „Why Metrology Cloud?“

✓ WP1: Architecture – Desiging a Secure Trust-Network

➢ WP1: Schema – Data Harmonization

• Introducing:

• MC Consortium Wiki

• MCoaT Demo

• MCoaS

• AuthStick

Schema Harmonization - Motivation

23

Schema Harmonization - Motivation

24

???

EVP

?

?

Schema Harmonization - Motivation

25

??

?

??

Schema Harmonization - Motivation

26

Schema Harmonization - Motivation

27

How do we achieve?

→ The Metrology Cloud Consortium Wiki

Topics

28

✓ Goals – „Why Metrology Cloud?“

✓ WP1: Architecture – Desiging a Secure Trust-Network

✓ WP1: Schema – Data Harmonization

➢ Introducing:

➢ MC Consortium Wiki

• MCoaT Demo

• MCoaS

• AuthStick

Schema Harmonization - Wiki

29

dev rev main

Three stages: „dev“, „rev“, „main“

❖ dev [Develop] - working space

❖ rev [Review] - voting process

❖ main [Accepted] - accepted schema

Schema Harmonization - Wiki

30

Metrology Cloud Consortium Wiki

process related data

❖ Unifying / Defining relevant tables / columns/keys

names / types / keys

❖ Collaborative schema design

❖ Allows working on the schema for process- and data-experts

❖ Decision History and data dictionary as output

❖ Direct export to Demonstrator MC2.0+

➢ https://wiki.metrologycloud.eu/

Schema Harmonization - Wiki

31

Schema Harmonization - Wiki

32

Schema Harmonization - Wiki

33

Schema Harmonization - Wiki

34

Topics

35

✓ Goals – „Why Metrology Cloud?“

✓ WP1: Architecture – Desiging a Secure Trust-Network

✓ WP1: Schema – Data Harmonization

➢ Introducing:

✓ MC Consortium Wiki

➢ MCoaT Demo

• MCoaS

• AuthStick

MCoaT

Metrology Cloud on a Table

Metrology Cloud Consortium Meeting Year 1

PTB BerlinWP1-Lead: Neumann, Prof. Dr. Nordholz

Dev-Team: Dohlus, Kammeyer, Nischwitz, Wetzlich, Yurchenko

Metrology Cloud Demonstrators

37

Metrology Cloud on a Table

38

Secure, process related data exchange between partners

❖ Input data

❖ Set access rights

❖ Query data / check

❖ Software update

❖ Conformity assessment

❖ Connections to MIs

Possible Actions Supported Processes

MI connected via

external system

MI connected

via the Internet

Consortium Consensus on

Harmonized Schema

Metrology Cloud on a Stick

MCoaT architecture

39

Node

Simulation

User

Interface

Demo

System

NOW

FINAL

Full Webfrontend

Now: User-Interface running

on same system as Node

Later: regular Web-Frontent

MCoaT architecture

40

I

n

t

e

r

n

e

t

Manufacturer

NMI

Market Surveillance

User

• 4 Stakeholder

Nodes

• 2 Measuring

Devices

❖MIs connected to the Metrology Cloud

❖directly to a node

❖via some network (i.e. the Internet)

❖Speak different protocols

❖OPCUA

❖REST/JSON

❖XML

41

Interfacing with MIs

❖Rock Pi 4B + 7’’ display

❖Full OPCUA support

❖Retrieve measurement data

❖Query version and log data

❖Perform software update

❖Use as research and development platform for secure MI

designs using our hypervisor

42

MCoaT MI

UI Picture

43

Demo Database

44

Field Type Description

MIID Integer Measuring Instrument ID

Name Varchar Name of the device

Manufacturer Varchar Manufacturer of the device

Munit Varchar Measured Unit

PicID Integer FK to Files-table / picture-file

ProdYear Integer Year of production

lastUpdate TimeStamp Time of last update to DR

isVerified Boolean State of verification marking

DocuID Integer FK to Files-table / document-file

Link Varchar Link to Measuring Instrument

Field Type Description

FileID Integer ID for every stored file

FileLocation Varchar Path / location on disc

FileTypeID Integer FK to FileTypes-Table

Measuring_Instruments Files

Field Type Description

FileTypeID Integer ID for every file-type to be stored

FileTypeDesc Varchar Describtion of file-type

File_Types

?

Example Low Level Process I

45

Query data

by MIID

Query for

specific MIID

Select * From

Measuring_Instruments

where MIID = X

Home-Node

Returning

result-sets

Stitching result-sets and

displaying result to user

Home-Node

46

Example Low Level Process II

Update data

by MIID and by Field

Update for

specific MIID

Home-Node

Connect only to

relevant node

or device

Home-Node

Report

success

Which node to

contact depends

on field chosen

for update

+ new Value

Inform user / display new value

Update value

47

Example Low Level Process III

Update rights

By Field

Update for

specific MIID

Home-Node

+ new State

Report success / display new state

High-Level Processes for MCoaT

48

Software Update and subsequent reverification

Start Process

Input:

• New version number

• Target-MIID

Assess Conformity

Accept Update Reverification

Apply Update

Respective MC-Users are

required to advance process

Result:

• Device updated

• Report success

Administration for MCoaT

49

Key Management Access Rights

Management

Process Monitoring

For

MIs

With

inth

eM

C

Software Update Communication Profile Management

of DigRep

MCoaT Presenat n

50

The MCoaT Demonstrator

The PTB

Metrology Cloud WP1 Team

proudly presents

Topics

51

✓ Goals – „Why Metrology Cloud?“

✓ WP1: Architecture – Desiging a Secure Trust-Network

✓ WP1: Schema – Data Harmonization

➢ Introducing:

✓ MC Consortium Wiki

✓ MCoaT Demo

➢ MCoaS

• AuthStick

You don‘t need to be a software expert

52

❖ All features

shown by

MCoaT are

integrated into

MCoaS

❖ Boot up VM

from USB and

start discovering

the MC

❖ 4 nodes on a

stick or 4 sticks

as MCoaT

Metrology Cloud On a Stick

53

User-advantages:❖ easy to start❖ no risk for user❖ no influence on other systems❖ Updates on Metrology Cloud

website

Get your first MC experiences easily

Topics

54

✓ Goals – „Why Metrology Cloud?“

✓ WP1: Architecture – Desiging a Secure Trust-Network

✓ WP1: Schema – Data Harmonization

➢ Introducing:

✓ MC Consortium Wiki

✓ MCoaT Demo

➢ MCoaS

• AuthStick

Secure authentication: requirements

55

Security aspects:

❖ cryptographic keys never leave the device

❖ A combination of factors appears to be a safer solution

❖ requested factor combination depends on security level

for operation

❖ Dynamical scoring-system

❖ 1-time logout-passwords

Usability requirements:

❖ all interfaces in one single gadget

❖ supports different devices:

❖ mobile phone

❖ pc/notebook

❖ tablet

Security Usability

From requirements to prototype

56

enter password on touchscreen[weakest factor]

use a NFC key fob [medium factor]

use the fingerprint authentification[strong factor]

posession of the USB-key[weak factor]

Requirements System design First prototype

Possible realisation

57

- Multi factor authentication with weighted factors

- Fingerprint sensor on the dongle allows secure authentication without

password entry

- USB-Dongle with NFC-interface for PC and mobile devices

- Small touch display allows password entry

Image sources:Mobiltelefon: https://cdn.tutsplus.com/mobile/uploads/2013/05/Ralf-NFC_Preview2@2x.pngFinger: https://d2v9y0dukr6mq2.cloudfront.net/video/thumbnail/uh59Wh0/finger-1-icon-cartoon-illustration-hand-drawn-animation-transparent_nyfxqs7y__F0004.png

Physikalisch-Technische Bundesanstalt

Braunschweig und Berlin

Abbestrasse 2-12

10587 Berlin

Maximilian Dohlus

Telefon:030 3481-7485

E-Mail: maximilian.dohlus@ptb.dewww.ptb.de

Thank you for your attention!

Questions?

Demo Recovery

59

Demo Recovery

60

Demo Recovery

61

Demo Recovery

62

Demo Recovery

63

Demo Recovery

64

Demo Recovery

65

Demo Recovery

66

Demo Recovery

67

Demo Recovery

68

Demo Recovery

69

Demo Recovery

70

Demo Recovery

71

Demo Recovery

72

Demo Recovery

73

Demo Recovery

74

Demo Recovery

75

Demo Recovery

76

Demo Recovery

77

Demo Recovery

78

Demo Recovery

79

MC Node Architecture

80

Metrological

Administration

Access Rights Authorisation

Signing

DLT

Logging

Encryption PKI

Public Key Infrastructures - PKI

81

❖ Smart contracts

❖ Distributed ledgers

❖ Digital document signing

❖ Confidential data exchange

between nodes

❖ Secure user authentication

and communication

PKI – DLT-based Approach

82

Consensus Block:

• approved by voting

• contains rootlike CA-cert

Metrological Administration Tasks

83

Software Update

Monitoring of operational Processes

Communication

Change and Administrative

Processes

Profile management of the Digital

Representations

Information Security Management (ISMS)

Key Management (PKI)

Incident Management

Certificate and Access Rights Management

Metrological

Administration

MCoat Initial State

84

Table with 4 Nodes and 2 Measuring Instrument placeholders

4 Nodes represent 4 main stakeholders (one Node each):

❖ Manufacturers

❖ PTB/NMI

❖ Market Surveillance

❖ Users

2 physical Measuring Instrument placeholders:

❖ IoT-MI

❖ MI connected only to USER-Node

All devices show their picture/logo, a log window (small) and an action

window (mainly):

❖ MIs display new states after update in action window

❖ Nodes use action window for MC-GUI

ICON

Action

windowLog

Initial Data

85

MIID Name Manufacturer MUnit PicID ProdYear LastUpdate isVerified DocuID Link

1Future-Scale 3000

Future Corp. Ltd. Weight 5 200901.01.2019 11:11:11

TRUE 6

2Future-Scale 4000

Future Corp. Ltd. Weight 4 201201.01.2019 11:11:11

TRUE 7

3Future-Scale 5000

Future Corp. Ltd. Weight 3 201501.01.2019 11:11:11

FALSE 8

4Future-Scale 6000

Future Corp. Ltd. Weight 2 201801.01.2019 11:11:11

TRUE 9

5Future-Scale 7000

Future Corp. Ltd. Weight 1 202101.01.2019 11:11:11

FALSE 10

Measuring_Instruments

FileTypeID FileTypeDescribtion

1 Pictures

2 Documentation

File_

TypesEntries of Files-table can

be determined from this.

Division of data

86

Fixed for all nodes: File_Types-table, Files-table

Data mirrored over all nodes

Data split vertically: Measuring_Instruments-table

MIID, Name, Manufacturer, DocuID, ProdYear

MIID, MUnit

MIID, isVerified, lastUpdate

MIID, picID

MIID, CurrentVersion (data directly from device)

Data relevant for

Digital Representation

87

Processes IV

Update rights

By Device (MIID)

Update for

specific MIID

Home-Node

Connect to

specified device

Home-Node

Report

success

+ new State

Inform user / display new value

Update access rights

Only for

User

Measuring

device

Schema Harmonization - Motivation

88

How do we achieve?

→ The Metrology Cloud Consortium Wiki

Conceivable Authentication Mechanism

89

❖ Multi factor authentication with weighted factors

❖ Secure authentication with fingerprint sensor on the dongle

❖ No passwords!

❖ USB-Dongle with NFC-interface for PC and mobile devices

Image sources:Mobiltelefon: https://cdn.tutsplus.com/mobile/uploads/2013/05/Ralf-NFC_Preview2@2x.pngFinger: https://d2v9y0dukr6mq2.cloudfront.net/video/thumbnail/uh59Wh0/finger-1-icon-cartoon-illustration-hand-drawn-animation-transparent_nyfxqs7y__F0004.pngDongle: https://upload.wikimedia.org/wikipedia/commons/b/b6/U2F.USB-Token.jpg

MC on a Stick

90

Development-advantages:❖ local feature testing❖ comfortable debugging❖ easy recovery

User-advantages:❖ self-contained VM-image ❖ easy to install❖ no risk for user❖ no influence on other systems❖ testable in VM or real HW

Get your first MC experiences easily