march 7, 2008security proposal 1 ccsds link security proposal ed greenberg greg kazz howard weiss...

March 7, 2008 Security Proposal 1

CCSDS Link Security Proposal

Ed Greenberg

Greg Kazz

Howard Weiss

March 7, 2008


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)


Method for including Security in CCSDS Frames

FrameHeader

SecurityHeader

OptionalTrailers

i.e. CLCW, CRCCurrent Std

FrameHeader

OptionalTrailers

i.e. CLCW, CRCProposed Std Frame Data Contents

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 user4. 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


CCSDS Frame Formats TM transfer Frame Primary Header

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

AOS Header

TransferFrame

SecondaryHeader

SSVDSpareFlags

TC transfer Frame Primary Header

SSVDSpareFlags

Note: Yellow area in each Frame type is used to flag that a security secondary header is included which immediately follows the primary header.


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?


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 SecondaryHeaderLength

AdditionalSecondaryHdr Follows

HeaderType

EncryptionProtocol

AuthenticationProtocol

Length ofSequenceNumber

SequenceNumber

AuthenticationField

Bits 82 6 Variable1 3 2 2 Fixed by Algorithm

Bytes 1 1 1 Variable


M_PDUHdr

• 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

2 Codeblock length -8 (i.e. 120 for 1k LDPC or 504 for 4k LDPC)


• 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


• 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

CRCSecurityHeader

Encrypted Zone


M_PDUHdr

• 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

ASM AOS HdrSecurityHeader Packet Data Field

4 6

Supportable Frame Formats-Forward AOS: Example-3 Security with no Insert Zone

2 109

Encrypted Data Zone


M_PDUHdr

• 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]

ASM AOS Hdr Security HdrInsert Zone

Cmd Packet Data Field

4 6

Encrypted Data Contents allows use of IP without IPSec

Supportable Frame Formats-Forward AOS: Example-4 Security within Insert Zone (4k LDPC at 72kbps)

23

Encrypted Data Zone

Voice61


• 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]

ASM TM HdrSecurity

Hdr Frame Data Field

4 6

Supportable Frame Formats-Return TM: Example - 6 With Security

Encrypted Data Zone

OptionalCLCW

4

Optional added Secondary Hdr

march 7, 2008security proposal 1 ccsds link security proposal ed greenberg greg kazz howard weiss...

Documents