1 / 56

Distributed Data Security for Factory Automation

Distributed Data Security for Factory Automation. Alfred C. Weaver Professor of Computer Science University of Virginia. Outline. Motivation for data security Proposed security architecture Web services Trust Authentication Authorization Federation Research issues.

meryle
Download Presentation

Distributed Data Security for Factory Automation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Distributed Data Security for Factory Automation Alfred C. Weaver Professor of Computer Science University of Virginia

  2. Outline • Motivation for data security • Proposed security architecture • Web services • Trust • Authentication • Authorization • Federation • Research issues

  3. Data Privacy and Security Plants PDAs Global Internet Processes Laptops Databases Desktops Cell phones

  4. Virtual Factory

  5. Risks • Access by unauthorized individuals • Access denied to authorized individuals • Identity theft and impersonation • Authentication techniques of varying reliability • Mobile access devices • Viruses and worms

  6. 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

  7. Outline • Motivation for data security • Proposed security architecture • Web services • Trust • Authentication • Authorization • Federation • Research issues

  8. Outline • Motivation for data security • Proposed security architecture • Web services • Trust • Authentication • Authorization • Federation • Research issues

  9. 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

  10. 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

  11. 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

  12. SOAP Example <soap:Envelope> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <!-- security credentials --> <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"> <from>22-342439</from> <to>98-283843</to> <amount>100.00</amount> <denomination>USD</denomination> </x:TransferFunds> </soap:Body> </soap:Envelope> TransferFunds (from, to, amount)

  13. Outline • Motivation for data security • Proposed security architecture • Web services • Trust • Authentication • Authorization • Federation • Research issues

  14. {Authentication, Credentials, Privileges} Trust Privileges What you can do Who you are Authentication What you have Credentials, attributes

  15. Outline • Motivation for data security • Proposed security architecture • Web services • Trust • Authentication • Authorization • Federation • Research issues

  16. Authentication • Biometric • based upon physical or behavioral characteristics • answers “who are you?” • Digital • something you have or know • Two-factor authentication • biometric + digital

  17. Identification vs. Verification • Identification • of all humans, which one are you? • Verification • does your biometric (bid sample) match a previously enrolled biometric template?

  18. Fingerprint Iris Retina Hand geometry Finger geometry Face geometry Ear shape Physical Biometrics • Palm print • Smell • Thermal face image • Hand vein • Fingernail bed • DNA

  19. Fingerprint Scanners Digital Persona U.are.U Pro HP IPAQ IBM Thinkpad T42

  20. 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 used

  21. Fingerprints 70 points of differentiation (loops, whirls, deltas, ridges) Even identical twins have differing fingerprint patterns False acceptance rate < 0.01% False rejection rate < 1.4% Can distinguish a live finger Fast to enroll Inexpensive (~$50-100) for the reader

  22. Iris Scans Iris has 266 degrees of freedom Identical twins have different iris patterns False acceptance rate < 0.01% False rejection rate < 0.01% Does take some time and controlled lighting to enroll Pattern is stored as a data template, not a picture Flash light to detect pupil dilation (prove live eye)

  23. 011010101111011110000001... 011010101100011110000111... Determining a Match • Enrollment produces a template • Bid sample produces another template • Hamming distance between them is the degree of difference

  24. 011010101111011110000001... 011010101100011110000111... Determining a Match • Enrollment produces a template • Bid sample produces another template • Hamming distance between them is the degree of difference

  25. Behavioral Biometrics Alfred C. Weaver • Signature • Voice • Keyboard dynamics

  26. Digital Techniques • PINs and passwords • E-tokens • Smart cards • RFID • X.509 certificates

  27. Stores credentials such as passwords, digital signatures and certificates, and private keys Some can support on-board authentication and digital signing eToken

  28. Smart Card • Size of a credit card • Microprocessor and memory • All data movements encrypted

  29. IC with antenna Works with a variety of transponders No power supply Supplies identity information Susceptible to theft and replay attacks RFID

  30. 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

  31. 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>

  32. 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>

  33. Outline • Motivation for data security • Proposed security architecture • Web services • Trust • Authentication • Authorization • Federation • Research issues

  34. 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

  35. SAML Assertions • An assertion is a declaration of facts about a subject • SAML has three kinds, all related to security: • authentication • attribute • authorization decision

  36. SAML Conceptual Model

  37. 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”

  38. 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>

  39. 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”

  40. 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>

  41. 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.

  42. <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> Example Authorization Decision Assertion

  43. Outline • Motivation for data security • Proposed security architecture • Web services • Trust • Authentication • Authorization • Federation • Research issues

  44. 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?

  45. Federated ATM Network Account Number and PIN Visiting Bank Network Funds Network of Trust Home Bank Network

  46. Administrative Decision IP/STS Yes Admin Get identity token 1 3 Requestor Resource 2 Administrator decides on per request basis

  47. Basic FederationDirect Trust Token Exchange IP/STS IP/STS Trust Get accesstoken Get identity token 1 2 Resource Requestor 3

  48. Trust Trust Indirect Trust IP/STS B IP/STS IP/STS A C 1 2 Resource Requestor 3 C trusts B which vouches for A who vouches for client

More Related