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 dynamicsaccess 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 N 2 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