60 likes | 280 Views
Security Association / Security Context. Bruno Saba DCT/TV/IN 03/05/2010. Security Association. Defines cryptographic communication parameters to be used by both the sending and receiving ends of a Secure Channel Secure Channel = One or more Global Virtual Channels (TM and AOS)
E N D
Security Association / Security Context Bruno Saba DCT/TV/IN 03/05/2010
Security Association • Defines cryptographic communication parameters to be used by both the sending and receiving ends of a Secure Channel • Secure Channel = • One or more Global Virtual Channels (TM and AOS) • One or more Global VC/MAP (TC) • SA uniquely identified by the Security Parameter Index (SPI) over a defined physical channel. The SPI is transmitted in each frame • Up to 254 simultaneous SA per physical channel • Each SA defines a cryptographic service : • Authentication Only (AO) • Encryption Only (EO) • Authenticated Encryption (AE) • At least one cryptographic key associated to each SA • SA can be pre-loaded prior to the launch, or dynamically created (mission dependant) Space Data Link Secure Protocol Simulator CNES DCT/TV/IN B. Saba 14/04/2010
Security Context • Defines cryptographic communication parameters to be used by both the sending and receiving ends of a Secure Channel • Secure Channel = • One or more Global Virtual Channels (TM and AOS) • One or more Global VC/MAP (TC) • SC uniquely identified by the Security Context Index (SCI) over a defined master channel. The SCI is transmitted in each frame • Up to 255 simultaneous SC per master channel • Each SC defines a cryptographic service : • Clear Mode • Authentication Only (AO) • Encryption Only (EO) • Authenticated Encryption (AE) • No cryptographic key associated to the SC • Key index transmitted in plaintext in the Security Header • SC are pre-loaded prior to the launch, NOT dynamically created Space Data Link Secure Protocol Simulator CNES DCT/TV/IN B. Saba 14/04/2010
Main Differences between SA / SC • Security Associations can be dynamically created, Security Contexts are only pre-loaded before flight and can not be changed in flight • For SA, this is a mission dependant feature • If SA are pre-loaded before launch and not modified on flight, then no difference between SA and SC on this point • Key management • Key directly associated with each Security Association • Key index transmitted in clear mode with Security Context concept • Max 254 pre-loaded keys with Security Association concept • Much more (K index length dependant) when using Security Context concept • If 254 pre-loaded keys is an acceptable limit, then no difference between SA and SC on this point • In each case, key management is to be defined (key revocation, key uploading, key activation, etc.) Space Data Link Secure Protocol Simulator CNES DCT/TV/IN B. Saba 14/04/2010
Conclusion • The main difference is in the key management • Key index transmitted in Security Header when using Security Context Concept • No key index transmitted when using Security Association concept • Less pre-loaded keys with Security Association concept • Max 254 pre-loaded keys when using SA • More key changes during satellite lifetime • Need to maintain a key change log file for deciphering old raw TM data • As the same SPI will be reused with different keys during satellite lifetime Space Data Link Secure Protocol Simulator CNES DCT/TV/IN B. Saba 14/04/2010
Proposition • Amend the proposed SDLS protocol standard • Add an additional attribute to SA : transmission of key index in-line or not. In this case, key index is no more an SA attribute • if key index transmitted in-line, add an additional field in security HDR (16-bit) Space Data Link Secure Protocol Simulator CNES DCT/TV/IN B. Saba 14/04/2010