Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The Role of the OSGi Gateway in GST Security Objectives and Architecture - Antonio Kung, Trialog, and Danny De Cock, K.U. Leuven

501 views

Published on

OSGi World Congress 2004

Published in: Technology
  • Be the first to comment

  • Be the first to like this

The Role of the OSGi Gateway in GST Security Objectives and Architecture - Antonio Kung, Trialog, and Danny De Cock, K.U. Leuven

  1. 1. © copyright 2004 by OSGi Alliance All rights reserved. Role of OSGi Gateways in GST Security Objectives and Architecture Antonio Kung Trialog, Danny DeCock KU Leuven
  2. 2. © copyright 2004 by OSGi Alliance. All rights reserved. 2 GST: Global System for Telematics • Open Market for Telematics Services • OSGi gateways will play a key role Open Telematics Market Service Provider Service Provider Service Provider End User End User End User Ease of Market Access Ease of Market Access Freedom of choice in Service Consumption Avoid unduly high barriers of market entry
  3. 3. © copyright 2004 by OSGi Alliance. All rights reserved. 3 European Project with 49 Partners FP6-2002-IST-1-507033 ®
  4. 4. © copyright 2004 by OSGi Alliance. All rights reserved. 4 7 Subprojects / 7 Test Sites • Open Systems • Security (SEC) • Service Payment • Certification • Rescue • Safety Channel • Enhance Floating Car Data • Gothenburg • Munich • Paris • Aachen • Stuttgart • Torino • London
  5. 5. © copyright 2004 by OSGi Alliance. All rights reserved. 5 SEC Subproject Vision • Future infrastructures – must meet security, privacy, and reliability requirements – are based on common approaches and mechanisms. • Deployment and operation of applications and infrastructures must relies on a proper trust value chain.
  6. 6. © copyright 2004 by OSGi Alliance. All rights reserved. 6 SEC Goals • Define an architecture and provide security mechanisms for secure telematics applications. – functional point of view (applications, services, user devices) – infrastructure point of view (networks, platforms) • Define roadmap for a trust value chain including certification requirements
  7. 7. © copyright 2004 by OSGi Alliance. All rights reserved. 7 SEC Partners
  8. 8. © copyright 2004 by OSGi Alliance. All rights reserved. 8 Introduction • Security is Transversal Security Business Aspects Security Technical Aspects Security Architecture Aspects Security Functional Aspects
  9. 9. © copyright 2004 by OSGi Alliance. All rights reserved. 9 Another View Overall Security Application Security Service Security Devices Security Interconnectivity Heterogeneous networks incl. Adhoc networks Service Deployment Platforms Operating System User Point of View Technology Point of View
  10. 10. © copyright 2004 by OSGi Alliance. All rights reserved. 10 Entities/Actors Vehicle Client System Service Centre Control Centre Payment Centre End-User Registration Authority Certification Authority Actors SEC Entities/Actors
  11. 11. © copyright 2004 by OSGi Alliance. All rights reserved. 11 Interactions between Entities Vehicle Client System Service Centre Payment Centre Billing Centre User Subscriptions Authentica- tion & Autho- risation Client System Management Control Centre End-User
  12. 12. © copyright 2004 by OSGi Alliance. All rights reserved. 12 Example : Family and Friends • Families A,B,C travel together. Friend D joins A family. – they set up an ad-hoc network capability (range of communication is 2 km) • A, B, C daughters install a small private chat application – they download it in a secure sandbox of the telematics control unit • B, C sons install software to allow interaction with their video game console • A,B,C download free software to allow display of the location of the 3 vehicles on their GPS display • D uses A vehicle to accesses services he has subscribed to
  13. 13. © copyright 2004 by OSGi Alliance. All rights reserved. 13 Example of Requirements • Functional Requirements – Secure session – Authentication & authorisation – Secure service activation – Policy enforcement – Federated identities • GST Entities Platform Requirements – Authentication & authorisation – Trusted components – Credential storage management – Client system tamper evident hardware – Client system trustworthy OS
  14. 14. © copyright 2004 by OSGi Alliance. All rights reserved. 14 Example of Requirements • Software Requirements – Bundle authentication – Bundle authorisation – Certification policy • Communication Requirements – Layered security architecture – Secure GST entity communication – Heterogeneous security chains
  15. 15. © copyright 2004 by OSGi Alliance. All rights reserved. 15 SEC Layered Architecture • Security aware GST entities follow a layered model Transfer Security App E2E Security Transfer Security App
  16. 16. © copyright 2004 by OSGi Alliance. All rights reserved. 16 Security Aware GST Entity • Has an authorization broker – validates whether certain actions can be allowed, e.g., incoming network traffic, software update,… • Has an authentication broker – validates authenticity of other GST entities and End users – authenticates data sent from this entity to another GST player • Includes a trusted component – stores the entity’s credentials (e.g., session keys, trusted certificates,…) – protects confidentiality and/or integrity of persistently stored data (e.g., log files, user data, system data,…) Transfer App Security Mechanisms Trusted Component Authentication Broker Authorization Broker
  17. 17. © copyright 2004 by OSGi Alliance. All rights reserved. 17 Example: from Service Center to Client System • Service Center sends data to a Client System: – Service Center uses its trusted component to authenticate the data for the Client System – Authenticated data is sent to the Client System (either directly or via a third party) Service Center sends data to a Client System • Client System receives data: – Authentication broker of the Client System uses its trusted component to validate the authenticity of the incoming data – Authorization broker validates where the data can be used for • Similar scenarios are used when sending data between other GST entities
  18. 18. © copyright 2004 by OSGi Alliance. All rights reserved. 18 Example : from Client System to Service Center • Client System sends data to a Service Centre: – The Authorisation Broker of the Client System checks whether sending data to the Service Centre requires end-user authentication – If yes, the end-user has to authenticate him/herself – If not, the authentication broker is used to authenticate the data • Authenticated data is sent to the Service Centre – Service Centre receives data: – Authentication broker of the Service Centre uses its trusted component to validate the authenticity of the incoming data – Authorisation broker validates where the data can be used for • Similar scenarios are used when sending data between other GST entities
  19. 19. © copyright 2004 by OSGi Alliance. All rights reserved. 19 Distributed Security Functions are Possible • A broker may contact remote brokers in order to carry out its task • The application layer and security layer can include distributed security functions – Single-Sign On is provided as a distributed interaction between authentication and authorization brokers
  20. 20. © copyright 2004 by OSGi Alliance. All rights reserved. 20 Trusted component Sealed in a tamper evident enclosure Credentials Key store •Private signing keys •Private decryption keys •Secret {en|de}cryption keys Certificate store •GTTP list of CAs •Commercial Root CAs Functionality •Authenticate data •Verify authenticated data •Decrypt encrypted data •Encrypt plaintext data •Generate key pair •Generate secret key •Generate random data •Reference time Implementationrelieson API Accessed by - Application - Middleware - Platform - Network
  21. 21. © copyright 2004 by OSGi Alliance. All rights reserved. 21 Impact on OSGi based Client System • Functional Requirements – Specific Bundles to provide • Secure session • Authentication & authorisation • Secure service activation • Policy enforcement • Federated identities – Could be promoted as GST SEC bundles
  22. 22. © copyright 2004 by OSGi Alliance. All rights reserved. 22 Impact on OSGi based Client System • Platform Requirements – Specific hardware to provide • Trusted component • Credential storage management • Client system tamper evident hardware – Specific software to provide in order to have multiple secure • Client system trustworthy OS – Could take advantage of initiative such as • Isolate JVM • Embedded FINREAD
  23. 23. © copyright 2004 by OSGi Alliance. All rights reserved. 23 Impact on OSGi based Client System • Software Requirements – Specific bundle policy • Bundle authentication • Bundle authorisation • Certification policy – Could involve a specific GST certification scheme
  24. 24. © copyright 2004 by OSGi Alliance. All rights reserved. 24 Impact on OSGi based Client System • Communication Requirements – Specific bundle policy • Layered security architecture • Secure GST entity communication • Heterogeneous security chains – Gateway should • allow for various security mechanisms • possibly manage security chains Node A in Vehicle Chain 1 Gateway Node C Service Provider E2E Security Chain 2
  25. 25. © copyright 2004 by OSGi Alliance. All rights reserved. 25 Impact on OSGi based Client System • Access to Non GST-Entities, e.g. – ECUs in the vehicle – Non GST Service Providers in the infrastructure • Use Firewalls at Client System level Legacy ECU Legacy Service Center Client System Firewall Legacy ECU Client System Firewall Legacy ECU Client System Firewall Legacy Service Center Control Center Firewall
  26. 26. © copyright 2004 by OSGi Alliance. All rights reserved. 26 SEC Timetable • Requirements : Nov 2004 • Architecture : Jul 2005 • Reference Implementation : Oct 2005 • Validation through test sites : Mar 2007
  27. 27. Antonio Kung Antonio.kung@trialog.com Danny De Cock danny.decock@esat.kuleuven.ac.be www.gstforum.org Thank you for your attention

×