1 / 7

Space Data Link Security (SDLS) protocol

Space Data Link Security (SDLS) protocol. Discussion of remaining technical issues Portsmouth, May 6-7, 2010. Position of SDLS protocol in Space Data Link protocol stack. for TC space data link stack :. Position of SDLS protocol in Space Data Link protocol stack.

burian
Download Presentation

Space Data Link Security (SDLS) protocol

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. Space Data Link Security (SDLS) protocol Discussion of remaining technical issues Portsmouth, May 6-7, 2010

  2. Position of SDLS protocol in Space Data Link protocol stack • for TC space data link stack : pied de page

  3. Position of SDLS protocol in Space Data Link protocol stack • for TM space data link stack : pied de page

  4. Position of SDLS protocol in Space Data Link protocol stack • for AOS space data link stack : pied de page

  5. Selection of SDU to be authenticated • Full transfer frame (apart from ECF and MAC) : • pro’s : • slightly improved integrity check of TF header & OCF (wrt ECF) • In TC : sequence preserving service still possible because SDLS authentication & integrity check performed before FARM • con’s : • different SDU for authentication (full frame) and encryption (frame data field) • SDLS protocol splitted in two sub-functions inserted at different positions in SDL protocol stack, more complex in terms of specification (4 service interfaces to specify instead of two) • Reporting of security fails • Transfer frames data field : • pro’s : • protocol simpler to specify and more modular to implement • security function can be inserted as a plug-in in existing implementation (e.g. : ESA packet TC decoder) • con’s : • no sequence preserving service possible in TC (TC frames can be discarded by SDLS protocol after validation by COP/FARM) pied de page

  6. Security objectives for authentication • general objectives : • integrity check • authentication of sender • enable anti-replay protection • trade-off for TC : • For unintentional errors : • already provided at frame level by BCH and frame CRC, but with lower performance than MAC • For intentional errors : • in no authentication of frame header : • possible attack on COP by sending BC frames (if BC frames are not protected for operational reasons), • will prevent sharing same Security Association on several VC, because VC switching will not be protected and several VC could use the same Security Context • Conclusion : protect frame header to protect VC switching pied de page

  7. Security objectives for authentication • trade-off for TM and AOS : • for unintentional errors : • already provided at frame level by RS (if used) and frame CRC, but with lower performance than MAC • For intentional errors : • in no authentication of frame header : • will prevent sharing same Security Association on several VC, because VC switching will not be protected and several VC could use the same Security Context • Conclusion : protect the frame header (+ sec header + insert ) by authentication • Note : • Potential concern with layering violation : if complete TF header is authenticated, authentication function would have to analyze frame to extract VCID and select correct SA. Potential solution : not authentication master frame count. pied de page

More Related