New Cryptographic Techniques for Active Networks

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