March 7, 2008Security Proposal 1 CCSDS Link Security Proposal Ed Greenberg Greg Kazz Howard Weiss March 7, 2008

Security Proposal 2 Objective Define a security protocol shim that can be incorporated into all the CCSDS TM, TC and AOS link protocols. The protocol should utilize a commercial security protocol that is analogous to that used for IPsec. The security protocol should be capable of protecting the contents of the frame as required –1. Encrypting traffic ( so it cannot be read by parties other than those for whom it is intended ) –2. Integrity validation ( ensuring traffic has not been modified along its path ) –3. Authenticating the peers ( ensuring that traffic is from a trusted party ) –4. Anti-replay ( protecting against replay of the secure session )

March 7, 2008Security Proposal 3 Method for including Security in CCSDS Frames Frame Header Security Header Optional Trailers i.e. CLCW, CRC Current Std Frame Header Optional Trailers i.e. CLCW, CRC Proposed Std Frame Data Contents 1.A flag bit in the Primary header of the frame identifies the presence of a secondary header. A “Security” secondary header shall be defined to enable this process. 2.The frame processing, except for data content parsing, can be accomplished without decryption allowing frame validation checking using CRC and use of CLCW for COP services. CLCW could optionally be included within encrypted data region if desired for missions that perform the COP at the POCC not at the station. 3.Security is applied by frame maker and decryption/authentication occurs at frame’s user 4.The Security process utilizes data fields in the primary and security headers Note: The TC and AOS specifications should be modified by converting a spare bit to signal the presence of the secondary (security) header. encrypted

March 7, 2008Security Proposal 4 CCSDS Frame Formats TM transfer Frame Primary Header AOS Header Transfer Frame Secondary Header SSVD Spare Flags TC transfer Frame Primary Header SSVD Spare Flags Note: Yellow area in each Frame type is used to flag that a security secondary header is included which immediately follows the primary header.

March 7, 2008Security Proposal 5 What’s needed in the Security Header? Conform to the CCSDS definition of Secondary header in TM spec –1 byte that contains Version and Length plus a second byte that identifies the secondary headers structure Should we provide for multiple “secondary” headers? –A Flag bit to indicate that another secondary header could be included signaling another header Need to Identify this Secondary Header as the Security Header –The TM specification requires that 255 secondary headers can eventually be identified Is there any data required for associating the sender and receiver –The S/C Id in primary header ties the S/C POCC to the S/C is that enough? –Should their be multiple associations for a single S/C ( i.e. different users on S/C) ? Provide a Security Sequence Number Field to prevent replay –How big and fixed or provide length and value fields? Identify Encryption Protocol being used per the private agreements –How many encryption protocols should we provide for? –Encryption protocol should be a protocol that is recommended by CCSDS for this purpose Identify Authentication Protocol being used per the private agreement –How many authentication protocols should we provide for? –Authentication protocol should be a protocol that is recommended by CCSDS for this purpose Provide for the Authentication Data field ( when used ) –Does a defining length field for this purpose need to be to included in header? Provide for padding (if required) –Does the defining length field for this purpose need to be included in header?

March 7, 2008Security Proposal 6 An Example Security Header Note: Combination of S/C ID a VC ID could be used to identify different security pairs Use TM specified Secondary Header form which provides for multiple secondary header types. –Version ID ( 2 bits ) –Length of Secondary Header ( 6 bits ) Identify this Secondary Header as the Security Header ( 8 bits ) Flag that another “Secondary” header follows ( 1 bit ) Length of Sequence Number Field ( 3 bits provides for a 0-7 byte sequence number field ) Identify Encryption Protocol Field ( 2 bits ) –Zero value means no encryption performed? Identify Authentication Protocol Field ( 2 bits ) –Zero value means no authentication included? Security sequence number length ( variable per value in Sequence length Field ) Authentication Data field ( fixed by chosen Authentication Protocol ) Version Secondary Header Length Additional Secondary Hdr Follows Header Type Encryption Protocol Authentication Protocol Length of Sequence Number Sequence Number Authentication Field Bits 8 26Variable 1 322Fixed by Algorithm Bytes111Variable

March 7, 2008Security Proposal 7 M_PDU Hdr 4 byte (64 symbol) [ ASM is synchronization for Codeblock, Frame ] 6 byte AOS Header –6 byte Primary Header S/C id ---- used for Layer 2 routing recipient VC id identifies frame structuring and possibly VC originator Added Flag bit is set to 0 to identify no secondary (Security) Header included 2 byte MPDU Header [ location of first byte of first packet header in IP Data Container Field ] Packet Data field ASM AOS Hdr ( see below ) Packet Data Field 4 6 Supportable Frame Formats-Forward AOS: Example-1- No Insert Zone, No Encryption 2Codeblock length -8 (i.e. 120 for 1k LDPC or 504 for 4k LDPC)

March 7, 2008Security Proposal 8 2 byte ASM 6 byte TC Header –S/C id ---- used with VC id for Layer 2 routing recipient –VC id identifies frame structuring and possibly VC originator –Added Flag bit is set to 0 to identify no secondary (Security) Header included TC Data Contents field CRC ASM TC Hdr ( see below ) Packet Data Field 2 6 Supportable Frame Formats-Forward TC: Example-2- No Encryption CRC

March 7, 2008Security Proposal 9 2 byte 6 byte TC Header –S/C id ---- used with VC id for Layer 2 routing recipient –VC id identifies frame structuring and possibly VC originator –Added Flag bit is set to 0 to identify the absence of a secondary Header TC Data field CRC ASM TC Hdr ( see below ) Packet Data Field 2 6 Supportable Frame Formats-Forward TC: Example-2a- With Encryption CRC Security Header Encrypted Zone

March 7, 2008Security Proposal 10 M_PDU Hdr 4 byte (64 symbol) 6 byte AOS Header –S/C id ---- used with VC id for Layer 2 routing recipient –VC id identifies frame structuring and possibly VC originator –Added Flag bit is set to 1 to identify secondary (Security) Header present Security Header 2 byte MPDU Header [ location of first byte of first packet header in IP Data Container Field ] Packet Container ASMAOS Hdr Security Header Packet Data Field 46 Supportable Frame Formats-Forward AOS: Example-3 Security with no Insert Zone Encrypted Data Zone

March 7, 2008Security Proposal 11 M_PDU Hdr 4 byte (64 symbol) [ ASM is synchronization for Codeblock, Frame, Cipher ] 6 byte AOS Header –S/C id ---- used with VC id for Layer 2 routing recipient ( i.e. different agency labs on ISS ) –VC id identifies frame structuring (include voice or not) and VC originator –Added Flag bit is set to 0 to identify the absence of a secondary Header Insert Zone [ size identified by VC id ] –Security Header included by management –3 byte Command Field option for Low latency or Hardware Command –61 bytes Voice ( contains up to 60 bytes of Voice ) 1 byte Voice Insert Header –Selected voice channel ID –Number of valid Codec data chunks inserted in Voice field ( each chunk=10 bytes ) 60 bytes Operational Voice Codec “Chunks” –Can contain up 6o 2-10ms Codec chunks –Delivery not dependent on Router or LAN 2 byte MPDU Header [ location of first byte of first packet header in IP Data Container Field ] Packet Data field [ size identified by VC id ] ASMAOS Hdr Security Hdr Insert Zone Cmd Packet Data Field 46 Encrypted Data Contents allows use of IP without IPSec Supportable Frame Formats-Forward AOS: Example-4 Security within Insert Zone ( 4k LDPC at 72kbps ) 2 3 Encrypted Data Zone Voice 61

March 7, 2008Security Proposal 12 4 byte (64 symbol) [ ASM is synchronization for Codeblock, Frame, Cipher ] 6 byte TM Header –6 byte Primary Header S/C id ---- used with VC id for Layer 2 routing recipient VC id identifies frame structuring ( include voice or not ) and VC originator Secondary Header Flag bit is set to 1 to identify presence of secondary Header Secondary Header (Security Shim) –Security Header Optional Additional Secondary Header –Up to 64 bytes in length Content field [ structure identified by VC id ] ASMTM Hdr Security Hdr Frame Data Field 46 Supportable Frame Formats-Return TM: Example - 6 With Security Encrypted Data Zone Optional CLCW 4 Optional added Secondary Hdr