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: –security associations –authorizations

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

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

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

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

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!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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