Trust and Security in the IDS - internationaldataspaces.org€¦ · Identity & Trust Management...

Gerd Brost

Senior Security Engineer

Fraunhofer AISEC

INDUSTRIAL DATA SPACE:TRUST & SECURITY IN THE IDS

© Fraunhofer 2

IDS Security Architecutre

„ad hoc“ communication relationships between partnersn Need to acquire trusted information about partner connector

Connecting industries with different needs and standardsn Need for an adaptable and flexible access control & usage control

Running third-party apps from app store(s) n Guarantee service level for app executionn Preventing apps from influencing connector/other apps

Challenges

© Fraunhofer 3

IDS Security Architecutre

Reuse existing approachesn „Do not reinvent the wheel“

Scalable and transparent trustn Baseline security a mustn Data souvereignity means freedom of choice

„Security pays off“n Adhering to better security levels offers access to more data sources

Design Principles

© Fraunhofer 4

IDS Security ArchitecutreEvolution of Security

State of the art

Industrial Data SpaceData Usage Control

Attribute based, fine grained access control

Support of security profiles

Trusted Platform

Trustworthy exchange protocol (RAT, Metadata)

Confidential, authentic communication

© Fraunhofer 5

IDS Architecture OverviewIDS Role

© Fraunhofer 6

IDS Architecture OverviewIDS Connectors as central component

IDS Connector IDS Connector

IDS Connector

IDS Connector

Enterprise A Enterprise B

VocabulariesApp Store

IDS ConnectorBroker

© Fraunhofer 7

IDS Security Architecture

n Industrial Data Space Project(s): BMBF & Fraunhofer-funded technology developmentn reference architecturen open source implementation Trusted Connector1n use case evaluations

n Industrial Data Space Association: User group of international enterprisesn provide input and requirementsn get use case evaluations, specifications, artefacts

n Standardisation of Trusted Connector as Industrial Gateway in DIN Spec 27070

n Certification scheme and accredited auditors

Establishing a secure (IoT) ecosystem

1https://github.com/industrial-data-space

© Fraunhofer 8

Design aspects of the Trusted ConnectorSeven properties of highly secure devices

Source: Galen Hunt and George Letey and Edmund B. Nightingale: The Seven Properties of Highly Secure Devices,Microsoft Research NExT Operating Systems Technologies Group, March 2017

Property Example / Question

Hardware-based root of trust Unforgeable cryptographic keys generated and protected by hardware. Physicalcountermeasures resist side-channel attacks.Does the device have a unique, unforgeable identity that is inseparable from thehardware?

Small trusted computing based Private keys stored in a hardware-protected vault, inaccessible to software. Division of software into self-protecting layers.Is most of the device’s software outside the device’s trusted computing base?

Defense in depth Multiple mitigations applied against each threat. Countermeasures mitigate theconsequences of a successful attack on any one vectorIs the device still protected if the security of one layer of device software is breached?

Compartmentalization Hardware-enforced barriers between software components prevent a breach in onefrom propagating to others.Does a failure in one component of the device require a reboot of the entire device toreturn to operation?

© Fraunhofer 9

Design aspects of the Trusted ConnectorSeven properties of highly secure devices (2)

Source: Galen Hunt and George Letey and Edmund B. Nightingale: The Seven Properties of Highly Secure Devices,Microsoft Research NExT Operating Systems Technologies Group, March 2017

Property Example / Question

Certificate-based Authentication Signed certificate, proven by unforgeable cryptographic key, proves the deviceidentity and authenticity.Does the device use certificates instead of passwords for authentication?

Renewable Security Renewal brings the device forward to a secure state and revokes compromised assetsfor known vulnerabilities or security breaches.Is the device’s software updated automatically

Failure Reporting A software failure, such as a buffer overrun induced by an attacker probing security, isreported to cloud-based failure analysis system.Does the device report failures to its manufacturer?

© Fraunhofer 10

Design aspects of the Trusted ConnectorSeven properties of highly secure device: AnswersProperty Architectural answer

Hardware-based root of trust Hardware roots of trust supported (e.g., TMP 2.0). SCDaemon abstracts underlyingroot of trust. Adaptions to virtual TPMs, Intel SGX enclave based attestation planned.

Small trusted computing based Trustme as computing base. Reduced kernel and Container Management Layer makecoputing base as small as possible.

Defense in depth Whitelist based integrity protection (secure boot, containrr integrity verification), remote attestation, least privilege isolation, network virtualization.

Compartmentalization Isolation of apps in Linux Containers, least privilege based isolation via Linux Security Module.

Certificate-based Authentication X.509 device certificates as identity root, ACME certificates for TLS tunnels, dynamicattriburtes via Dynamic Attribute Provioming Service.

Renewable Security Remote update of containers and kernel.

Failure Reporting Event based, integrity protected audit log.

© Fraunhofer 11


Trusted Platform

Identity & Trust Management

Access & Usage Control

Trustworthy Communication

Security building blocks

© Fraunhofer

Trusted Platform


© Fraunhofer 13

Trusted Platform

Platform for edge-devices and sensorsn Powerful server (x86, PPC)n Cloud Service (AWS ECS)n Embedded device (Raspberry/ARM)

Data Processingn High-volume message routing between apps

and connectors

Execution of 3rd party applicationsn Securely isolated data appsn Trusted Remote Execution

Trustworthy software stackn HW TPM+Integrity Measurementn Remote attestation to confirm security

profiles

Usage/data flow controln Data is processed in accordance with data

privacy/usage restrictionsn Separation of concernn Time-to-liven …

Trusted IDS Connector

Linux container + LSM

TPM 2.0 integration

LUCON Usage Control

EIP Engine

"IDS Protocol"

"IDS Protocol"

© Fraunhofer 14

Trusted PlatformRouting

n Controlled data workflows enable access and usage control

Trusted ConnectorCore Container

Routing Engine

Container Management Layer

Cont

aine

r M

anag

er

Usa

geCo

ntro

l M

anag

er

Acc

ess

Cont

rol

Man

ager

Kernel

Service Container

PEP

Rout

ing

Man

ager

IDSC

P Co

mpo

nent

PEP

PDP

PDP

PIP

PIP

Aggregation Service

Service Container

Data Service

Data access requestSubject Identifier, Attribute set

© Fraunhofer 15

Trusted Platform

n Concepts and models forn Secure updatesn Service development and deployment

n Trust management for all software components

Software Lifecycle

© Fraunhofer 16

Trusted PlatformSecurity feature definition

Aspect Level 0 Level 1 Level 2

Integrity protection and verification None Local Integrity Protection Remote integrity verification

Connection authentication None Server side only authentication Mutual authentication (both sides present id token / certificate)

Service isolation None Process group Isolation Least privilege based Isolation

Scope of integrity protection / verification

None Kernel & Core Container Kernel & Core Container & Application Containers

App Execution Resources None Local enforcement Remote verification

Data usage control support None Usage control policy enforcement Remote policy compliance verification

Audit logging None Local logging capabilities & integrity protection Remote audit log tracing

Local data confidentiality None Secure data erasure Local full data encryption

© Fraunhofer 17

Trusted PlatformSecurity features Trusted Connector 11/2018

Aspect Level 0 Level 1 Level 2

Integrity protection and verification None Local Integrity Protection Remote integrity verification

Connection authentication None Server side only authentication Mutual authentication (both sides present id token / certificate)

Service isolation None Process group Isolation Least privilege based Isolation

Scope of integrity protection / verification

None Kernel & Core Container Kernel & Core Container & Application Containers

App Execution Resources None Local enforcement Remote verification

Data usage control support None Usage control policy enforcement Remote policy compliance verification

Audit logging None Local logging capabilities & integrity protection Remote audit log tracing

Local data confidentiality None Secure data erasure Local full data encryption

© Fraunhofer 18

Trusted Platform

Baseline profilen Authenticated, encrypted communicationn Isolation between appsn Basic loggingn Admin user account protectionn -> Protection against baseline threats

Security profiles

Trusted Profilen Strong isolation between appsn Resource protection of appsn Integrity protection of software (Apps, OS)n Audit loggingn Secure data erasuren Hardware based trust (HW trust anchor)n Remote integrity verification

Trusted Profile Plusn All of the aboven Protection of data while in

memoryn Protection against malicious

administrators

© Fraunhofer 22


Digital identity Set of attributes related to an entity (Organization name,

email, DNS address)

Identity Provider (IdP) Someone who can issue and verify these attributes

Certificate Authority (CA) The entity that issues digital certificates that contain

attributes

IDS Certification body Entity that assesses parties in the IDS and grants

certification levels

An “IDS certificate of compliance” is not a technical certificate (e.g. X.509)

Definitions

© Fraunhofer 23


n The Industrial Dataspace Association has its own Certification Authority/Identity Providern This role is sub-contracted to specialized partner (e.g., D-Trust etc.) .

n IDS Certification body assesses partners and requests the CA to issue certificates:n to organization.n to connectors.

n Dynamic attributes are handled by a special service, avoiding the need for regular re-issuance of certificates and enabling privacy of properties.

Baseline principles

© Fraunhofer 25

Identity & Trust ManagementTrust Infrastructure

IDS Infrastructure

IDS Software Trust Repository

Certificate Authority (CA)

Dynamic Attribute Provisioning Service

Authorization Service

Broker etc.

IDS Participant Domain

IDS Connector

Verify Integrity Check Result

Obtain and verify X.509 certificates

Verify certification status of participant / connector

Obtain access token for resource access

Mandatory

Optional

© Fraunhofer 26


n Authenticationn Make sure we talk to the right entityn X.509 Certificate as root of trustn Signed by Certification Authority (CA)

n Authorizationn Allow access to a resourcen JSON Web Token (JWT) for delegated authorizationn Dynamic attributes embeddable (e.g., group membership, workflow membership)

Divide authentication and authorization

© Fraunhofer 27


n At least two (technical) certificate typesn X.509 organization certificate

n Contains organizational attributesn Certification status (IDS compliance level)n Validity

n X.509 connector certificaten Contains connector attributes

n E.g., Fingerprints of deployed software stack for remote attestation, IP addressn Attribute revocation means certificate revocation!n Thus, we want to keep dynamic attributes from being part of the certificates.

Two levels of certificates

© Fraunhofer 28

Identity & Trust ManagementPKI Structure (preliminary)

Trust Provider

IDS Certification Authority (CA)

Device / Connector

Sub CA

Software Developer

Sub CA

Software Authority

Sub CA

n Definition of Sub-CAs

n Increased flexibility

n Separation of concerns

n Enables complex trust management scenarios

n E.g., software signing

TLS Sub CA

© Fraunhofer 31

Identity & Trust ManagementIdentity Architecture

IDS Participant DomainIDS Participant

IDS Connector

IDS Infrastructure

TLS Sub-CA

TLS Sub-CACA

Dynamic Attribute Provisioning Service

(DAPS)

TLS Certificate

Request Dynamic Attribute Token

ACME ProtocolACME SERVER

Device Sub-CA

Privacy CA

Device Certificate

Attestation Certificate

Manual

Deployment

Optional

Dynamic Attribute TokenOAuth

© Fraunhofer 32

Identity & Trust ManagementAttributes

Organisation

IDS Connector

IDS membership status

Status validity date

Certification level

Certification validity

Certification level

Certification validity

Security profile

runs

© Fraunhofer 33

Identity & Trust ManagementAuthorization flow

Device Sub-CA

IDS Participant 2 Domain

IDS Infrastructure

IDS Participant 1 Domain

Connector

X.509 Device Certificate

Connector

X.509 Device Certificate


Data Service

2: Present X.509 TLS Certificate, establish TLS

3: Request access token with Identity Token

2b: Verify certificate


4: Access resource (multiple times)

Dynamic Attribute Provisioning Service (DAPS)

1: Present X.509 Device Certificate, request Dynamic Attribute Token


© Fraunhofer 34

IDS Data Consumer Domain

IDS Connector (C2)

Consumer Service (CS)

IDS Participant Domain

IDS Connector (C3)

Authorization Service (AS)

IDS Data Provider Domain

IDS Connector (C1)

Provider Service (PS)


AB(C)

(D)

E

A: call C3/token endpoint with Client Credentials (X.509 Cert)

B: Issue JWT-1{Attribute_list, client_id, aud: idsAS:*}

Attribute list examples: Security level, certification status, …)

C (optional): Hand in JWT-1, request JWT-2 {scope: C1/PS}

D: Use Rule Engine for access decision, issue JWT-2{aud: C1}

E: Connect via IDSCP (Auth by Client Certificate + JWT-2)

DB/ Rule engine

© Fraunhofer

Trustworthy Communication


© Fraunhofer 36

Trustworthy communication

n Trusted Connectors communicate with each other through an IDS protocol (IDSP)n Secure Websockets over TLSn Remote Attestation & Meta Data Exchange: Proof of trusted platform configuration

n Exchange of payload data with an associated usage policyn Connection of backend protocols through protocol adapters. 200+ supported protocols

n REST, MQTT, OPC-UA, AMPQ

IDS Communication Protocol (IDSCP)

Custom Container Core Container

Data Service Message Queue

Data Flow Control

Connection Mgmt.

Trusted Container Management Layer

Core Container

Message Queue

Data Flow Control

Connection Mgmt.

Trusted Container Management Layer

Custom Container

Target App

IDS Protocol

Policy Set

© Fraunhofer 37

Trustworthy communication

n Support of Remote Attestationn Mutual verification of security features

n Hardware n Software

n Based on TPM security architecture with a privacy CA

n Different stages of trustn Untrustedn Trusted CML and Coren Trusted CML, Core and Containers

IDS Communication Protocol

© Fraunhofer 39


n Access Control regulates requests to connector endpoints (endpoint granularity)

n Attribute-based rules based onn Requester's ID token attributes

n Descriptive attributes such as energy sector, medical, certification leveln Requester's TPM keyn Remote attestation values ("PCR values")´

n After access is granted, no further control is possible

Access control

© Fraunhofer 40


n Regulates processing of data at the level of data flows

n Supports sticky policies attached to messages & enforced at trusted remote connector orsession based policy exchange

n Central messaging engine enforces policies throughout data lifetimen Enforcing data protection, anonymization, data leak prevention, time to live

n Partner companies are not considered inherently „evil“n Usage control does not fully protect against malicious data consumersn IDS delivers tools and processes to support companies in fulfilling their obligations

Usage Control

© Fraunhofer 41


Trustworthy enforcement of remote data usage

Bind data usage to requirements. Data must only be used for a specific purpose or for a limited time.

Definition of legitimate data flows

Auditable data protection compliance by design. Proves that data routes comply with privacy requirements.

Data Usage Control

© Fraunhofer 42


Different approaches in the IDSn LUCONn IN2DUCEn Data Provenance Trackingn Application Control Language

Data Usage Control

© Fraunhofer 46

Trusted Connector Open SourceTwo main projects on Github

Core Platformn Java-basedn ISDC protocol (Remote Attestation Endpoint)n Message Routingn Usage Controln Administration web interfacen Runs on Docker or trust|me

trust|me OSn Hardened OSn Linux container isolationn LIghtweight container management layer (cmld)n TPM daemon (tpmd)n Network isolation (netfilter)

© Fraunhofer 47

Trusted Platform

n Containers with different trust levelsn Service bundles seperated through containersn Trusted container for security and system functionality

Container Management Layer / trust|me OSTrusted

Connector

Hardware

Linux

Kernel

Core Container

Core Container Stack

vService

Linux OS Stack

Virtualization

Layer

Service Container n

Service Stack

vService

Linux OS Stack

Service Container 1

Service Stack

vService

Linux OS Stack

Container Management Security Management

Netfilter Cgroups Capabilities

Full Disk Encryption Container Isolation LSMNamespaces

Sensor/Actor InterfaceSensor/Actor Interface Sensor/Actor InterfaceNetwork Interface TPM

© Fraunhofer 48

Core ContainerContainer Operations Module

Trusted Platform

n Containers with different trust levelsn Service bundles seperated through containersn Trusted container for security and system functionality

Core Container

IDSC

P Co

mpo

nent

OSGi FrameworkJava Virtual Machine

Cont

aine

r M

anag

emen

t In

terfa

ce

Secu

rity

Man

agem

ent

Inte

rface

Cont

aine

r Man

ager

Conn

ectio

n M

anag

er

Rout

ing

Man

ager

Audi

t Log

ging

Usa

geCo

ntro

l

Acce

ss C

ontr

ol

Man

ager

Adm

inist

ratio

n In

terfa

ce

Linux OS Stack

© Fraunhofer 49

ImplementationSoftware framework

Smart Sensor

IDS Connector ProducerCore Container

Container Managemement Layer

TPMd

Custom Container 1

OPC-UA ClientSystem Adapter

Attestation Manager

Custom Container 2

ExternalData Service

Container Manager

IDS Connector ConsumerCore Container

Container Managemement Layer

TPMd

Camel

Custom Container 1

Data Service

IDS Protocol

Custom Container 3

Data Filtering

Sensor Application

OPC-UA Server

TPMd

Data Signing

System / HW Interfaces

System / HW Interfaces

Policy Manager

CamelPEP

IDS Protocol EndpointPEP

IDS Protocol Endpoint

Admin GUI Admin GUI

Route Manager

Configuration Manager

Camel IDS Protocol Endpoint

Attestation Manager

Policy Manager

Route Manager

Container Manager

Configuration Manager

Message Processor

Message Processor

Custom Container 4

Production Feedback

PolicyEnforcement

Trusted Remote Execution

Usage Control Policy

Remote Attestation

MetadataTransport

PolicyNegotiation

Access Control

Usage Control

© Fraunhofer 50

Implementation

Technologiesn Container Layer: Docker/trustme for x86/trustme for PPC

n Message routing: Apache Camel 2.19

n Application Server: Karaf/OSGi 4.1

n Platform: x86 Standard Linux (docker)/trustme Linux

n TPM: TPM2.0 Emulator

n UI: Angular 2 Web Interface

Technology stack of reference implementation

Similar to Eclipse Kura

© Fraunhofer 51

Standardization progress DIN SPEC 27070

n DIN SPEC 27070 - “Referenzarchitektur eines Security Gateways zum Austausch von Industriedaten und Diensten” -> Reference architecture of a security gateway for exchange of industrial data and services”

n Core Topicsn Specification of functional and non-functional requirements for interoperability between

connectors and IDS infrastructuren Specification of security requirements

n “Base” gateway with mandatory set of security features as baseline variantn “Trust” gateway with focus on trust and securityn “Trust+” gateway with protection against manipulation by admins

Focus of standardization

© Fraunhofer 52

IEC 62443 as a foundation for DIN SPEC 27070Industrial communication networks – Network and system security

© Fraunhofer 53

DIN SPEC 27070 foundations

n IEC 62443-3-3, IEC 62443-4-1 available

n IEC 62443-4-2 still draft but getting pretty stable

n Focus of DIN SPEC 27070 on requirements for the gateway itself

n Requirements for development and deployment processes as pointers to 62443-4-1

n Detailed organizational definitions (DIN 27001 etc. ) out of scope or only as reference

Baseline standards

© Fraunhofer 54

DIN SPEC 27070Overall architecture

n Define requirements of a “Trusted Connector” and its ecosystem.n DIN SPEC may not be used for “closed shop” solutions: Requirements must be abstract and

product independent.n We need to be careful with IDS specifics.

© Fraunhofer 55

DIN SPEC 27070Gateway architecture

n No implementation requirements should be defined. n How requirements are fulfilled is free to decided for implementor.n Abstract target architecture for connector as a guideline.

© Fraunhofer 56

DIN SPEC 27070 foundations

n Access Control (AC): control access to selected devices, information or both

n Use Control (UC): control use of selected devices, information or both

n Data Integrity (DI): ensure the integrity of data on selected communication channels

n Data Confidentiality (DC): ensure the confidentiality of data on selected channels

n Restricted Data Flow (RDF): restrict the flow of data on communication channels

n Timely Response to Events (TRE): respond to security violations by notifying proper authority

n Resource Availability (RA): ensure the availability of all network resources to protect against

denial of service attacks.

Foundational requirements of IEC 62443

© Fraunhofer 57

DIN SPEC 27070Security levels

n SLs are currently in discussion and interpreted quite differently.n SL-4 unreachable for most current applications.n Even SL-3 hard to achieve.

Security Level

Description

SL-1 Prevent the unauthorized disclosure of information via eavesdropping

SL-2 Prevent the unauthorized disclosure of information to an entity actively search- ing for it usingsimple means with low resources, generic skills and low motivation.

SL-3 Prevent the unauthorized disclosure of information to an entity actively search- ing for it usingsophisticated means with moderate resources, IACS specific skills and moderate motivation.

SL-4 Prevent the unauthorized disclosure of information to an entity actively search- ing for it usingsophisticated means with extended resources, IACS specific skills and high motivation.

© Fraunhofer 58

DIN SPEC 27070Security level mapping

n Mapping of security levels as a “mapping vector”.n Direct link to IEC 62443 without the need to adapt complete security levels.n Levels are not straightforward. Requirements are embedded into lifecycle and testing

considerations. Implications are not yet clear.

Base Security Profile

Trust Security Profile

Trust+ Security Profile

62443-IAC SL2 SL3 SL362443-UC SL1 SL2 SL262443-SI SL1 SL3 SL362443-DC SL1 SL3 SL362443-RDF SL1 SL3 SL362443-TRE SL1 SL3 SL362443-RA SL1 SL3 SL362443-NDR SL1 SL3 SL3

© Fraunhofer 59

DIN SPEC 27070

n Communication securityn More detailed requirements for ciphers & crypton Remote integrity verification, remote attestation

n Data usage controln Information flow control and usage control requiremements

n Information modeln Requirements towards the information model and metadata

n Identity & access management requirementsn Certificates, DAPS, ...

n Broker integrationn Broker interaction requirements

n Operating system securityn Audit logging

Additional requirements

© Fraunhofer 60

DIN SPEC 27070

n Many requirements not „complete“ yet. Many details still in discussion.n Even if we were ready: Some things will never be at the level of a detailed specification. n Rather a testbed will be used to verify IDS connectivity. n But this is „closed shop“.

n IDS specifics are hard to define in a generic DIN (SPEC). n We need to be detailed enough to have a document that is helpful. n We need to be generic enough to make it applicable out side of the IDS.

Challenges

© Fraunhofer 61

DIN SPEC 27070

n Additional requirements and needs towards the DIN SPEC?n What is needed for a “good and useful“ DIN SPEC?n What requirements should be taken care of?n How detailed can we get?

n Relating DIN SPEC with IDS certificationn We will need certain specialized profiles for certain connector typesn IACS, Medical, public data, ...n If the profiles are met (e.g., component compliant to 62443 as described and to the

additional requirements, it is easier to get a IDS certification.n But how should we link these two layers?

Workshop part

Gerd Brost

[email protected]

Fraunhofer AISEC

»INDUSTRIAL DATA SPACE«

Trust and Security in the IDS - internationaldataspaces.org€¦ · Identity & Trust Management...

Documents

Transcript of Trust and Security in the IDS - internationaldataspaces.org€¦ · Identity & Trust Management...