1 / 14

CCSDS Link Security Proposal

CCSDS Link Security Proposal. Ed Greenberg Greg Kazz Howard Weiss March 13, 2008. Objective. Define a security protocol shim that can be incorporated into all the CCSDS TM, TC and AOS link protocols.

bebe
Download Presentation

CCSDS Link Security Proposal

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. CCSDS Link Security Proposal Ed Greenberg Greg Kazz Howard Weiss March 13, 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 commercial security algorithms 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) Security Proposal

  3. SLE Client for Forward & Return Services = SCaN Provided = User Provided Station POCC Configuration & Cipher Key Control SLE-FCLTU Service Client Framer AES Encipher Compose Frame LDPC encoder Randomize Add Sync Add fill Pkt when required SDUs to F-CLTU Provider Radiation Performance SLE-FCLTU Service Production Insert Data Capture F-CLTU PDUs & Radiation log Datagrams Forward Frame Release Return Configuration & Cipher Key Control SLE-RxF Service Client SLE-RxF Service Production Frame Handler AES Decipher Insert, CLCW and Packet Extractors SDUs from RxF Provider Acquisition performance Annotated AOS Frames Service Monitor Data Insert Data Datagrams CLCW Security Proposal

  4. Example Frame Processing SLE RxF Provider Service (Telemetry Processing at Station) • Delimit frame • De-randomize frame • Decode frame • Verify frame validity (error free) • Requires access to CRC if used • May require access to CLCW if used at station for COP-1 SLE RxF Client Service (Telemetry Processing at POCC) • Provide Frames to Mission Processing Mission Telemetry Services • Validate/Authenticate Frame (user/unchanged) • Decipher • Delimit Frame internal fields • Extract Packets Security Proposal

  5. Method for including Security in CCSDS Frames Optional Trailers i.e. CLCW, CRC Frame Header Current Std Frame Data Contents Optional Trailers i.e. CLCW, CRC Frame Header Security Header Proposed Std Frame Data Contents encrypted 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. 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. Security is applied by frame maker and decryption/authentication occurs at frame’s user 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 a secondary (security) header. Security Proposal

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

  7. 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 (fixed or provide length and value fields) in clear or encrypted? • Select an Encryption options (i.e. “key set”) established by private agreements • How many encryption options should we provide for? • Encryption algorithm should be a protocol that is recommended by CCSDS for this purpose • Identify Authentication Protocol being used per the private agreement • How many authentication options should we provide for? • Authentication algorithm should be a protocol that is recommended by CCSDS for this purpose • Provide for Authentication Data field (Is a length field need for this purpose?) • Provide a data field for secondary header (Is a length field need for this purpose?) • Provide for padding (if required) • Should we create a protocol for key management? Security Proposal

  8. An Example Security Header Secondary Header Length Additional Secondary Hdr Follows Encryption Protocol Authentication Protocol Sequence Number Authentication & Secondary Data Field(s) Length of Sequence Number Version Header Type Bits 2 6 3 2 2 Variable variable 8 1 Bytes 1 1 1 Variable 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 and/or Authentication option selection field(s) (4 bits) • 2 Split fields 2 bits each or a 4 bit field for pre-defined combine options? • Security sequence number length (variable per value in Sequence length Field) • Authentication Data field (fixed by chosen Authentication Protocol) Security Proposal

  9. Supportable Frame Formats-Forward AOS: Example-1- No Insert Zone, No Encryption M_PDU Hdr Packet Data Field ASM AOS Hdr (see below) 2 Codeblock length -8 (i.e. 120 for 1k LDPC or 504 for 4k LDPC) 4 6 • 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 offirst byte of first packet header in IP Data Container Field] • Packet Data field Security Proposal

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

  11. Supportable Frame Formats-Forward TC: Example-2a- With Encryption Security Header CRC Packet Data Field ASM TC Hdr (see below) 6 2 • 2 byte • 6 byte TC Header • S/C id ---- used with VC idfor Layer 2 routing recipient • VC id ----- identifies frame structuring and possibly VC originator • Reassigned Flag bit is set to 1 to identify the absence of a secondary Header • TC Data field • CRC Encrypted Zone Security Proposal

  12. Supportable Frame Formats-Forward AOS: Example-3 Security with no Insert Zone Security Header M_PDU Hdr ASM AOS Hdr Packet Data Field 4 6 109 2 • 4 byte (64 symbol) • 6 byte AOS Header • S/C id ---- used with VC idfor 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 offirst byte of first packet header in IP Data Container Field] • Packet Container Encrypted Data Zone Security Proposal

  13. Supportable Frame Formats-Forward AOS: Example-4 Security within Insert Zone (4k LDPC at 72kbps) Insert Zone M_PDU Hdr ASM AOS Hdr Packet Data Field Security Hdr Cmd Voice 4 6 3 61 2 Encrypted Data Zone • 4 byte (64 symbol) [ASM is synchronization for Codeblock, Frame, Cipher] • 6 byte AOS Header • S/C id ---- used with VC idfor 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 offirst byte of first packet header in IP Data Container Field] • Packet Data field [size identified by VC id] Encrypted Data Contents allows use of IP without IPSec Security Proposal

  14. Supportable Frame Formats-Return TM: Example - 6 With Security Security Hdr Optional added Secondary Hdr Optional CLCW ASM TM Hdr Frame Data Field 4 6 4 • 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 Header • Secondary Header Flag bit is set to 1 to identify presence of additional Header • Optional Additional Header • Up to 64 bytes in length • TM Data Content field [structure identified by VC id] Encrypted Data Zone Security Proposal

More Related