trust and security in the ids - internationaldataspaces.org€¦ · identity & trust management...
TRANSCRIPT
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
IDS Security Architecture
Trusted Platform
Identity & Trust Management
Access & Usage Control
Trustworthy Communication
Security building blocks
© Fraunhofer
Trusted Platform
IDS Security Architecture
© 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
Identity & Trust Management
IDS Security Architecture
© Fraunhofer 22
Identity & Trust Management
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
Identity & Trust Management
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
Identity & Trust Management
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
Identity & Trust Management
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
Authorization Service
Data Service
2: Present X.509 TLS Certificate, establish TLS
3: Request access token with Identity Token
2b: Verify certificate
2b: Verify certificate
4: Access resource (multiple times)
Dynamic Attribute Provisioning Service (DAPS)
1: Present X.509 Device Certificate, request Dynamic Attribute Token
1b: Verify certificate
© 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)
Authorization Service
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
IDS Security Architecture
© 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
Access & Usage Control
IDS Security Architecture
© Fraunhofer 39
Access & Usage Control
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
Access & Usage Control
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
Access & Usage Control
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
Access & Usage Control
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 moti- vation.
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