1 / 25

New Cryptographic Techniques for Active Networks

New Cryptographic Techniques for Active Networks. Sandra Murphy Trusted Information Systems March 16, 1999. New Crypto Techniques. Goal: Investigate existing, extended, new and AN enabled cryptographic techniques needed for the unique Active Network security challenges for:

flower
Download Presentation

New Cryptographic Techniques for Active Networks

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. New Cryptographic Techniques for Active Networks Sandra Murphy Trusted Information Systems March 16, 1999

  2. New Crypto Techniques Goal: Investigate existing, extended, new and AN enabled cryptographic techniques needed for the unique Active Network security challenges for: • security associations • authorizations

  3. Approach: • Review the requirements of active networks • Review the constraints imposed by the active network environment • Survey existing techniques for usefulness • Generate new specifications for new or extended crypto techniques

  4. Work completed and in progress • Review of authorization, integrity, and confidentiality requirements of active code, node and active packet • Study constraints imposed on cryptographic solutions by active network environment • Consider mobile agent/ mobile code research • Compare requirements and constraints to existing techniques

  5. Constraints: • Packets can be modified in transit • Round trip paths are frequently asymmetric • Participants in communication not always known before communication begins • current techniques: participants are a pair or an amorphous group • AN: participants are learned in sequence in real-time • Timeliness and scalability are requirements

  6. Requirements: Authentication • Source authentication will be crucial • Authentication of code author could be important (e.g., PLAN Switchlets) • Authentication of code attributes could be important (e.g., evaluation) • Authentication of packet change history could be important

  7. Requirements: Packet Integrity • Active code can change its own active packet • e.g., WebTV demo • EE (or another service installed in EE) can change packet • e.g., TTL-like resources, Protocol Boosters • NodeOS can change active packet • An active node is like a Super NAT box!

  8. Requirements: EE and Node Integrity • If API permits change, then integrity is subject to compromise • The EE’s and the Nodes can protect themselves through the policies they enforce

  9. Requirements: Confidentiality • The Node protects its own confidentiality by enforcing its own policy • The EE must trust the Node to keep confidentiality, but it may protect itself from Active Code or other EE’s • The Active Code must trust both the Node and the EE to keep confidentiality, but it may protect itself from other Active Code

  10. Scenarios • Identified characteristics of various AN scenarios affecting the cryptographic requirements • Network search by traffic content • Information Gathering • Scout/Settler (FBAR) • Active Firewall • others

  11. Scout/Settler Checks • Source authorized to create flow • Source authorized to resource usage request • Scout source matches ID of saved state • Settler matches source that owns flow • Settler matches scout that created flow • Settler sent by destination • Data authorized by source of scout • Data within flow authorization

  12. Characteristics were: • path dynamics access control • data secrecy payload • entities involved in cryptographic associations • duration of cryptographic associations • trust granted to node and EE • persistent state left in node

  13. Scout/Settler Characteristics • dynamic path, public data • variable payload, • packets, all nodes on path, user, flows involved • associations last for duration of scout-led flow • persistent state left in node • nodes are trusted

  14. Confidentiality of data (0) If data is not needed in interior, • if destination is known, use public key encryption • if destination is not known, create a key, encrypt the data, send the key later to destination - could use team or threshold cryptography to respond

  15. Confidentiality of data (1) Encrypt hop-by-hop • Trust problems: • trust all nodes • or identify and avoid untrusted nodes (2) Choose encryption key EK, encrypt data, encrypt EK hop-by-hop • Trust problems: • trust all nodes • or identify and avoid untrusted nodes • no PFS

  16. Confidentiality of data (3) Pre-distribute encryption key EK (group key distribution), encrypt data • no need to check nodes for trust • group key management difficult and costly, reasonable only for long duration of association • group unknown in general • PFS depends on group key distribution technique

  17. Confidentiality of data (4) Agree on an encryption key EK among the group of nodes involved in path, encrypt data • no need to check nodes for trust • group agreement techniques of N2 cost • group unknown • but extensions to group agreement technique may be suitable for use while a flow is established • PFS provided

  18. Confidentiality of data (5) Encrypt data in key specific to each node on the path • in general the nodes are not known ahead of time

  19. Confidentiality of code • Cannot use (0), but can use (1) - (5) • (6) Use encrypted execution techniques • (7) Use environmental key - computable by code in the clear

  20. Authentication of data • (1) Authenticate hop-by-hop • no source authentication unless all nodes are trusted • (2a) Sign with private key, authenticate everywhere • gives source authentication, but slow

  21. Authentication of data • (2b) MAC with symmetric key, encrypt symmetric key hop-by-hop • all nodes trusted or • identify and avoid untrusted nodes • (3) Create group key and distribute, use for MAC or signature • group authentication • authentication only at trusted nodes • plus problems of group key distribution

  22. Authentication of data • (4) Agree on symmetric key and use MAC • group agreement costly • group unknown • extensions for flows may be useful • (5) MAC with separate symmetric key for each node in path • but path not generally known

  23. Authentication of changed data • (0) Accept all changes, as long as the authentication on original packet is valid • (1) Send private signing key along with packet, using some “confidentiality of data” technique to keep it confidential, use to resign as packet changes • (2) Nest changes and signatures as addendum on packet

  24. Authentication of changed data • (3) Establish trust relationships with modifiers • if large number of modifiers, no better than (2)

  25. Directions • Crypto hash-chaining • USC/ISI work (CLIQUE) and authenticated group D-H • Considering a variant of some group D-H for flows • Investigating separation of forward and back channels

More Related