Distributed Data Security for Factory Automation

transcript

Alfred C. WeaverProfessor of Computer

ScienceUniversity of Virginia

Outline

Motivation for data security Proposed security architecture

Web services Trust Authentication Authorization Federation

Research issues

Data Privacy and Security

Plants

ProcessesDatabases

Desktops

Laptops

Cell phones

Global Internet

Virtual Factory

Access by unauthorized individuals Access denied to authorized

individuals Identity theft and impersonation Authentication techniques of

varying reliability Mobile access devices Viruses and worms

Risk Mitigation Requirements

Establish and maintain trust between data requestor and data provider

Techniques must be applicable to both humans and software

Trust decisions must be made without human intervention

Outline

Research issues

Outline

Research issues

Security Architecture

Based upon web services useful functionality exposed on the

WWW provide fundamental, standardized

building blocks to support distributed computing over the internet

applications communicate using XML documents that are computer-readable

Why Web Services?

Internet provides a powerful, standardized, ubiquitous infrastructure whose benefits are impossible to ignore provided that access is reliable,

dependable, and authentic World-wide acceptance

preferential way to interconnect applications in a loosely-coupled, language-neutral, platform-independent way

Web Services

Built on three primary technologies Simple Object Access Protocol (SOAP)

specifies format and content of messages Web Services Description Language

(WSDL) XML document that describes a set of SOAP

messages and how they are exchanged Universal Description, Discovery, and

Integration (UDDI) searchable "whitepage directory" of web

services

SOAP Example<soap:Envelope>xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header>

<s:credentials xmlns:s="urn:examples-org:security">

<username>Alfred Weaver</username><password>jdb5eifgh7a</password>

</s:credentials></soap:Header><soap:Body>

<x:TransferFunds xmlns:x="urn:examples-org:banking">

</soap:Body></soap:Envelope>

TransferFunds (from, to, amount)

Outline

Research issues

Who you are

Authentication

{Authentication, Credentials, Privileges}

Outline

Research issues

Authentication

Biometric based upon physical or behavioral

characteristics answers “who are you?”

Digital something you have or know

Two-factor authentication biometric + digital

Identification vs. Verification

Identification of all humans, which one are you?

Verification does your biometric (bid sample)

match a previously enrolled biometric template?

Physical Biometrics

Fingerprint Iris Retina Hand geometry Finger geometry Face geometry Ear shape

Palm print Smell Thermal face

image Hand vein Fingernail bed DNA

Fingerprint Scanners

HP IPAQDigital Persona U.are.U Pro IBM Thinkpad T42

False Acceptance/Rejection

False acceptance rate (FAR) incorrectly matches a bid sample to

an enrolled template this is very bad FAR must be very, very low

False rejection rate (FRR) fails to match a legitimate bid sample

to an enrolled template this is an annoyance FRR must be low if technique is to be

Fingerprints

70 points of differentiation (loops, whirls, deltas, ridges)Even identical twins have differing fingerprint patternsFalse acceptance rate < 0.01%False rejection rate < 1.4%Can distinguish a live fingerFast to enrollInexpensive (~$50-100) for the reader

Iris Scans

Iris has 266 degrees of freedomIdentical twins have different iris patternsFalse acceptance rate < 0.01%False rejection rate < 0.01%Does take some time and controlled lighting to enrollPattern is stored as a data template, not a pictureFlash light to detect pupil dilation (prove live eye)

Determining a Match

Enrollment produces a template Bid sample produces another template Hamming distance between them is

the degree of difference

011010101111011110000001...011010101100011110000111...

Determining a Match

Enrollment produces a template Bid sample produces another template Hamming distance between them is

the degree of difference

011010101111011110000001...011010101100011110000111...

Behavioral Biometrics

Signature Voice Keyboard dynamics

Alfred C. Weaver

Digital Techniques

PINs and passwords E-tokens Smart cards RFID X.509 certificates

eToken

Stores credentials such as passwords, digital signatures and certificates, and private keys

Some can support on-board authentication and digital signing

Smart Card

Size of a credit card Microprocessor and memory All data movements encrypted

RFID IC with antenna Works with a

variety of transponders

No power supply Supplies identity

information Susceptible to theft

and replay attacks

X.509 Certificates

Certificate issued by a trusted Certificate Authority (e.g., VeriSign)

Contains name serial number expiration dates certificate holder’s public key (used for

encrypting/decrypting messages and digital signatures)

digital signature of the Certificate Authority (so recipient knows that the certificate is valid)

Recipient may confirm identity of the sender with the Certificate Authority

Authentication Token

<TrustLevelSecToken> <CreatedAt> 2005-09-20T08:30:00.0000000-04:00 </CreatedAt> <ExpiresAt> 2005-09-21T08:30:00.0000000-04:00 </ExpiresAt> <UserID> 385739601 </UserID> <TokenIssuer> http://cs.virginia.edu/TrustSTS.asmx </TokenIssuer> <TrustAuthority> http://cs.virginia.edu/TrustAuthority.asmx </TrustAuthority></TrustLevelSecToken>

Authentication Token

<TrustLevelSecToken> <CreatedAt> 2005-09-20T08:30:00.0000000-04:00 </CreatedAt> <ExpiresAt> 2005-09-21T08:30:00.0000000-04:00 </ExpiresAt> <UserID> 385739601 </UserID> <TrustLevel> Fingerprint </TrustLevel> <AuthenticationMethod> Digital Persona U.are.U </AuthenticationMethod> <TokenIssuer> http://cs.virginia.edu/TrustSTS.asmx </TokenIssuer> <TrustAuthority> http://cs.virginia.edu/TrustAuthority.asmx </TrustAuthority></TrustLevelSecToken>

Outline

Research issues

Security Assertion Markup Language (SAML)

Applications require interoperable security solutions that transcend the boundaries of single security domains

Interoperable exchange of security information is essential to enable web single sign-on distributed authorization services securing electronic transactions

SAML addresses these issues

SAML Assertions

An assertion is a declaration of facts about a subject

SAML has three kinds, all related to security:

authentication attribute authorization decision

SAML Conceptual Model

AuthenticationAssertion

AttributeAssertion

AuthorizationDecisionAssertion

AuthenticationAuthority

AttributeAuthority

Policy DecisionPoint

Policy EnforcementPoint

Policy Policy Policy

Credentials Collector

System Entity

Application Request

Authentication Assertion

An issuing authority asserts that subject S was authenticated by means M at time T

Example subject “Alfred C. Weaver” was authenticated by “password” at time “2005-09-18T10:02:00Z”

Example Authentication Assertion

<saml:Assertion> AssertionID=“128.9.167.32.12345678” Issuer=“Robotics Corporation” IssueInstant=“2005-09-19T10:02:00Z”> <saml:Conditions NotBefore=“2005-09-19T10:02:00Z” NotAfter=“2005-09-23T10:02:00Z” /> <saml:AuthenticationStatement> AuthenticationMethod=“password” AuthenticationInstant=“2005-09-18T10:02:00Z”> <saml:Subject> <saml:NameIdentifier SecurityDomain=“robotics.com” Name=“Alfred C. Weaver” /> </saml:Subject> </saml:AuthenticationStatement></saml:Assertion>

Attribute Assertion

An issuing authority asserts that subject S is associated with attributes 1, 2, 3… with attribute values a, b, c...

Example: “Alfred C. Weaver” in domain

“robotics.com” is associated with attribute “Position” with value “Plant Manager”

Example Attribute Assertion

<saml:Assertion …> <saml:Conditions …/> <saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier SecurityDomain=“robotics.com” Name=“Alfred C. Weaver” /> </saml:Subject> <saml:Attribute AttributeName=“Position” AttributeNamespace=“http://robotics.com”> <saml:AttributeValue> Plant Manager

</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement></saml:Assertion>

Authorization Decision Assertion

An issuing authority decides whether to grant the request: by subject S for access type A to resource R given evidence E

The subject could be a human or software

The resource is any object data, web page, web service, etc.

Example Authorization Decision Assertion

<saml:Assertion …> <saml:Conditions …/> <saml:AuthorizationStatement>

Decision=“Permit” Resource=“http://www.robotics.com/production.html”> <saml:Subject> <saml:NameIdentifier SecurityDomain=“robotics.com” Name=“Alfred C. Weaver” /> </saml:Subject> </saml:AuthorizationStatement></saml:Assertion>

Outline

Research issues

Federation

Web services single sign-on How can identity, once legitimately

established in one trust domain, be reliably and securely shared with another trust domain?

How does authentication transfer? What are you authorized to do in a

different trust domain?

Federated ATM Network

Account Numberand PIN

Home Bank Network

Visiting Bank Network

Funds Network of Trust

Administrative Decision

Get identityGet identitytokentoken 11

Requestor

IP/STS

Administrator decides on per request basis

Resource

Basic FederationDirect Trust Token Exchange

TrustTrust

Get identityGet identitytokentoken

Get accessGet accesstokentoken11

IP/STS IP/STS

Requestor

Resource

Indirect Trust

TrustTrust

C trusts B which vouches for A who vouches for client

IP/STS

Requestor Resource

System Design

Outline

Research issues

Research Challenges

Authentication tokens SAML permits enumeration, but not

substitution, of acceptable tokens Trustworthiness varies even within a

technology, but SAML does not capture this distinction

Our TrustLevel concept is just a beginning; trust is more complicated than a number

Research Challenges

Authorization rules Human organizations are complex,

and so are their rules Role delegation Human/computer interface

Research Challenges

Federation Currently an infant science Many issues surround trust

management establishment representation exchange enforcement storage negotiation

Research Challenges

Tools and techniques how to specify access policies locate policy inconsistencies human/computer interface

Formalisms need formal methods to structure our

thoughts, processes and implementations

need proofs of correctness

Distributed Data Security for Factory Automation

Documents