OMG DDS Security Submission Presentation (September 2013 - 6th Revised Submission)

1,655 views
1,664 views

Published on

This is the presentation on the 6th Revised Submission to the OMG DDS Security specification.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,655
On SlideShare
0
From Embeds
0
Number of Embeds
549
Actions
Shares
0
Downloads
33
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

OMG DDS Security Submission Presentation (September 2013 - 6th Revised Submission)

  1. 1. Your  systems.  Working  as  one.   DDS  SECURITY   6th  Revised  Submission  (Joint)   Presented  at  OMG  Mars  Task  Force  on  September  24,  2013   Doc  num:  mars/2013-­‐09-­‐09   SpecificaTon  lead:   Gerardo  Pardo-­‐Castellote,  Ph.D.   CTO,  Real-­‐Time  InnovaTons,  Inc.   SubmiVers:   Real-­‐Time  InnovaTons,  Inc.   PrismTech  Corp.   eProsima  (supporter)   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved  
  2. 2. Outline  for  DDS  Security  Spec   •  Status  recap   •  Scope   •  Threats   •  Summary  of  RFP  requirements   •  SpecificaTon  details   –  Overview   –  Security  Model   –  DDS  &  RTPS  support  for  security   –  Security  Plugin  Architecture   •  Security  Plugins   –  AuthenTcaTon  plugin   –  AccessControl  plugin   –  Cryptographic  plugin   –  DataTagging  plugin   –  DataLogging  plugin   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   2  
  3. 3. Status  recap   •  Started  with  two  separate  submissions  by  RTI   and  PrismTech   •  As  of  the  December  2012  all  joined  the  RTI   submission   •  Several  reviews,  last  one  in  Berlin  idenTfied  a   couple  of  vulnerabiliTes   – Sequence  Number  AVack  on  reliable  channels   – Cuckoo  aVack  on  ParTcipant  GUID   •  Most  current  version  cleaned  spec  and   addresses  idenTfied  vulnerabiliTes   •  Some  under-­‐specified  issues  remain     10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   3  
  4. 4. Scope   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   4  
  5. 5. Security  as  a  system  problem   •  UlTmately  security  is  a  system  property   –  Involves  hardware,  soaware,  humans,   procedures…   •  Most  directly  related:   1.  Securing  the  data-­‐centric  bus   2.  IntegraTng  across  security  domains   3.  Securing  the  operaTng  system   4.  Securing  the  hardware  &  soaware   configuraTon   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   5   Scope  of   the  RFP   Out   of  Scope  
  6. 6. Scope  of  the  DDS  Security  RFP   Three  security  boundaries   •  Boundary  security   •  Transport-­‐Level     – Network  (layer  3)  security   – Session  (layer  4/5)  security   •  Fine-­‐grained  Data-­‐Centric   Security   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   Ul5mately  you  need  to  implement  the  3  of  them   6  
  7. 7. Fine-­‐Grained  Data-­‐Centric  Security   •  Access  control  per  Topic   •  Read  versus-­‐write  permissions   •  Field-­‐specific  permissions  (not  addressed)   Topics   10/9/13   7  ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved  
  8. 8. Threats   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   8  
  9. 9. Threats   1.  Unauthorized  subscripTon   2.  Unauthorized  publicaTon   3.  Tampering  and  replay     4.  Unauthorized  access  to  data   by  infrastructure  services     10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   9   Alice:  Allowed  to  publish  topic  T   Bob:  Allowed  to  subscribe  to  topic  T   Eve:  Non-­‐authorized  eavesdropper     Trudy:  Intruder   Trent:  Trusted  infrastructure  service   Mallory:  Malicious  insider  
  10. 10. Data-­‐centric/mulTcast  Insider  Threats     •  Two  insider  threats  affecTng  (mulTcast)  data-­‐ centric  systems  are  of  unique  significance   1.  Reader  mis-­‐behaves  as  unauthorized  writer   An  applicaTon  uses  knowledge  gained  as  authorized   reader  to  spoof  the  system  as  a  writer   2.  Compromise  of  Infrastructure  Service     A  service  that  is  trusted  to  read  and  write  data  on  behalf   of  others  (e.g.  a    persistence  service  )  becomes   compromised     10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   10  
  11. 11. Reader  mis-­‐behaves  as  unauthorized   writer   •  SituaTon:   –  Alice  -­‐    creates  a  Crypto  Key  per  Topic/DataWriter   –  Alice  -­‐  shares  its  Key  with  all  intended  readers  as  needed  to  mulTcast   –  Mallory  –  is  an  authorized  reader  so  it  has  Alice’s  key   –  Mallory  –  behaves  maliciously  and  uses  Alice’s  key  to  create  fake  UDP  messages  pukng   Alice’s  informaTon  (IP,  Port,  GUIDs,  etc.)  but  with  bad  data.   •  ImplicaTons:   –  Bob  sees  message  from  Mallory  and  processes  it  believing  it  is  from  Alice   –  Mallory  can  provide  a  system-­‐wide  failure  for  all  subscribers  to  topic  T,  making  them   process  wrong  data,  delete  instances,     –  Depending  on  the  Topic  this  can  be  catastrophic  for  the  system   •  Notes:   –  The  problem  is  that  all  secrets  shared  by  Alice  and  Bob  are  also  known    to  Mallory   •  So  the  aVack  cannot  be  solved  with  a  MAC  or  HMAC  if  Alice’s  key  is  also  shared  with  all   readers…   –  The  problem  can  be  solved  with  a  digital  signature  but  that  is  1000X  slower  than  a  MAC   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   11  
  12. 12. Session  Sequence  Number  AVack   •  Background:   –  Reliable  protocols  rely  on  a  session_id  and  a  sequence   number  to  avoid  duplicates  and  detect  message  loss   –  RTPS  protocol  can  use  GAP  messages  and  HeartBeat  messages   to  advance  the  session  (DataWriter)  sequence  number   •  Vulnerability:   –  An  aVacker  can  spoof  a  packet  with  the  session  ID  and   Hearbeat/GAP  causing  the  DataReader  to  advance  the  session   sequence-­‐numbers  blocking  future  messages  recepTon   –  AVacker  only  needs  GUID  of  the  DataWriter  to  aVack,  which   can  be  obtained  from  snooping  traffic.   –  AaVack  can  be  used  to  prevent  the  AuthenTcaTon  of   legiTmate  ParTcipants   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   12  
  13. 13. Cuckoo  AVack  on  GUID   •  Background:   –  DDS  DomainParTcipants  are  idenTfied  by  unique  GUID,   Readers/Writers  derive  their  GUID  from  it.   –  GUID  used  to  uniquely  idenTfies  the  RTPS  sessions  and  the   locaTon  of  each  parTcipant   •  Vulnerability:   –  An  aVacker  with  legit  IdenTty  can  authenTcate  using  the     GUID  of  another  ParTcipant   –  AVacker  with  be  accepted  with  “cuckooed”  GUID  blocking   legiTmate  ParTcipant  from  using  its  GUID   –  AVacker  only  needs  GUID  of  the  ParTcipant  to  aVack,  which   can  be  obtained  from  snooping  traffic.   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   13  
  14. 14. Summary  of  RFP  requirements   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   14  
  15. 15. RFP  Mandatory  Requirements   Proposals  shall  define  …   6.5.1    …  a  Plasorm  Independent  Security  Model  for  DDS     independent  of  the  programming  language  used…   6.5.2    …  a  collecTon  of  Plasorm  Independent  IntercepTon   Points  and    SPIs  …   6.5.3  …    built-­‐in  Plasorm  Independent  Security  Plugins  that   implement  the  Plasorm  Independent  Interfaces   6.5.4    …  plasorm  specific  mappings  for  the  built-­‐in  plugins  to   all  the  language  PSMs  supported  by  DDS   6.5.5  …    how  the  DDS  Interoperability  Wire  Protocol  is  used   to  allow  DDS  applicaTons  to  interoperate  securely   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   15  
  16. 16. Mandatory  Requirements  6.5.1:   Security  Model   The  Security  Model  for  DDS  shall  …   6.5.1.1    …  support  mechanisms  that  establish  the  ability  for  a  DDS  ParTcipant  to  run  in  a   plasorm   6.5.1.2    …  support  mechanisms  to  configure  and  access  the  credenTals  of  the  underlying   DDS  ParTcipants  …   6.5.1.3  …    allow  specificaTon  of  authorizaTon  policies,  controlling    [1]  Joining  a  DDS  Domain    [2]  Access  to  DDS  Discovery  Data    [3]  Publishing  a  DDS  Topic,    [4]  Subscribing  to  a  DDS  Topic    [5]  Publishing  on  a  DDS  ParTTon,  [6]  Subscribing  on  a  DDS  ParTTon   6.5.1.4    …  include  the  concept  of  data  tagging   6.5.1.5  …    support  mechanism  for  ensuring  data  integrity,  including    [1]  traceability,  pedigree,  and  tamper    [2]  digital  signatures    [3]  data  encrypTon    [4]  use  of  different  keys  for  data  from  different  DataWriters   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   16  
  17. 17. Mandatory  Requirements  6.5.2:     Set  of  IntercepTon  Points  and  SPIs   The  Plugin  SPIs  shall  …   6.5.2.1    …  allow  applicaTons  to  exchange  credenTals  with  a  DDS  ParTcipant    [1]  exchanging  credenTals  for  authenTcaTon    [2]  delegaTon  of  authority  for  authenTcaTon   6.5.2.2    …  allow  an  external  plugin  to  perform  all  the  authorizaTon  funcTons      [1]  full  support  of  the  authorizaTon  policies    [3]  support  delegaTon  of  authority    [4]  support  delegaTon  of  authority  separately  for  each  DDS  Topic   6.5.2.3  …    allow  an  external  plugin  to  perform  all  the  tagging  and  tag-­‐accessing  funcTons   6.5.2.4    …  allow  an  external  plugin  to  perform  all  the  encrypTon  and  decrypTon   funcTons   6.5.2.5  …    external  plugin  to  perform  all  the  digital  signing  and  verificaTon  funcTons   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   17  
  18. 18. RFP  OpTonal  Requirements   Proposals  may  define  authorizaTon  policies  that  control    …   6.6.1  …  the  content  a  DDS  ParTcipant  is  allowed  to  publish  on  a  Topic.   6.6.2  …  the  content  a  DDS  ParTcipant  is  allowed  to  subscribe  on  a  Topic..   6.6.3  …  the  QoS  Policies  a  DDS  ParTcipants  can  use  when  publishing  a  Topic   6.6.4  …  the  QoS  Policies  a  DDS  ParTcipant  can  use  when  subscribing  to  a   Topic.   Proposals  may  define  …   6.6.5  …  data-­‐tagging  plugins  that  apply  different  tags  for  each  data-­‐sample   published  by  a  DDS  DataWriter.   6.6.6  …  built-­‐in  plugins  that  interoperate  with  standard  authenTcaTon  and   authorizaTon  protocols  and  services,  such  as,  LDAP  and  SAML.   6.6.7  …  a  PSM  mapping  of  the  DDS-­‐RTPS  Interoperability  Wire  Protocol  to  a   secure  transport,  such  as,  DTLS.   6.6.8  …  a  PSM  of  the  DDS-­‐RTPS  Interoperability  Wire  Protocol  allowing   interoperability  over  UnidirecTonal  Transports.   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   18  
  19. 19. Overview  of  DDS  Security  spec.   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   19  
  20. 20. Submission  Guiding  Principles   •  Performance  &  Scalability   –  Do  not  impact  parts  of  the  system  that  do  not  have  security  needs   –  Allow  opTng  out  of  specific  features  such  as  MAC,  EncrypTon.  Digital  Signature  with  sufficient   granularity   –  Limit  use  of  asymmetric  keys  to  discovery  &  session  establishment     –  Support  MulTcast   •  Robustness  &  Availability   –  Be  robust  to  the  failure  or  compromise  of  any  single  component.   –  Limit  privileges  of  infrastructure  services  and  relays   –  Avoid  centralized  policy  decisions/services   –  Avoid  mulT-­‐party  key  agreement  protocols   •  Fitness  to  data-­‐centric  model   –  Express  policies  and  permissions  in  terms  of  familiar  DDS  terminology  and  objects   –  Support  all  of  DDS:  consumpTon  of  samples  out  of  order,  best  efforts,  Tme  filters,  history  cache,   etc.   •  Leverage  exis5ng  technologies   –  Support  plugging  in  exiTng  technologies  for  ciphers,  MAC,  PKI   •  Ease  of  use  &  Flexibility   –  Do  not  preclude  integraTng  with  their  exisTng  security  and  crypto  infrastructure.   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   20  
  21. 21. Audience  and  Purpose  for  this  SpecificaTon   •  Audience:   –  DDS  vendors/implementers,  not  the  users  of  DDS   •  Purpose:   –  Define  a  Security  Model  for  DDS  systems   –  Define  concrete  IntercepTon  points  in  the  middleware   where  SPI  interfaces  must  be  called   –  Define  concrete  SPI  Interfaces  vendors  must  invoke  at  the   IntercepTon  Points  and  the  behavior  upon  various   returns   –  Define  specific  SPI  implementaTons  to  the  extent   required  for  interoperability   –  NOT  guidance  to  users  implemenTng  secure  DDS   systems   –  NOT  defini5on  of  security  technologies  beyond  what  is   required  to  implement  the  specificaTon   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   21  
  22. 22. DDS  Security  covers  4  related  concerns   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   22   Security  Plugin   APIs  &  Behavior   DDS  &  RTPS  support   for  Security   Buil5n  Plugins   Security  Model  
  23. 23. Security  Model   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   23  
  24. 24. Security  Model   •  A  security  model  is  defined  in  terms  of:   – The  subjects  (principals)   – The  objects  being  protected   •  The  operaTons  that  are  protected  on  the  objects   – Access  Control  Model   •  A  way  to  map  each  subject  to  the  objects  they  can   perform  operaTons  on  and  which  are  the  allowed   operaTons   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   24   MR#  6.5.1  
  25. 25. Security  Model  Example:   UNIX  FileSystem  (simplified)   •  Subjects:    Users,  specifically  processes  execuTng  on  behalf  of  a  specific  userid   •  Protected  Objects:    Files  and  Directories   •  Protected  OperaTons  on  Objects:   –  Directory.list,  Directory.createFile,  Directory.createDir,  Directory.removeFile,   Directory.removeDir,  Directory.renameFile   –  File.view,  File.modify,  File.execute   •  Access  Control  Model:   –  A  subject  is  given  a  userId  and  a  set  of    groupId   –  Each  object  is  assigned  a  OWNER  and  a  GROUP   –  Each  Object  is  given  a  combinaTon  of  READ,  WRITE,  EXECUTE  permissions   for  the  assigned  OWNER  and  GROUP   –  Each  protected  operaTon  is  mapped  to  a  check,  for  example   •   File.view  is  allowed  if  and  only  if     –  File.owner  ==  Subject.userId  AND  File.permissions(OWNER)  includes  READ   –  OR  File.group  IS-­‐IN  Subject.groupId[]    AND  File.permissions(GROUP)  includes  READ   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   25  
  26. 26. DDS  Security  Model   •  Subjects:    DDS  DomainParTcipant  (ParTcipant  GUID)   •  Protected  Objects:    DDS  Domain  and  DDS  Topic   •  Protected  Opera5ons  on  Objects  (logical  view):   –  DomainParTcipant.join   –  DomainParTcipant.set_read_parTTons    .set_write_parTTons   –  Topic.create   –  Topic.set_qos   –  Topic.set_reader_qos   –  Topic.read   –  Topic.set_writer_qos   –  Topic.write   –  Topic.create_instance   –  Topic.update_instance   –  Topic.dispose_instance   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   26   MR#  6.5.1  
  27. 27. Mapping  of  DDS  API  to  protected  operaTons   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   27   DDS  API  Call     Protected  Opera5on   DomainParTcipantFactory.create_parTcipant   Discovery.match_remote_parTcipant   DomainParTcipant.join   DomainParTcipant.create_publisher   Publisher.set_qos   DomainParTcipant.set_write_parTTons   DomainParTcipant.create_subscriber   Subscriber.set_qos   DomainParTcipant.set_read_parTTons   DomainParTcipant.create_topic   Discovery.dicover_topic   Topic.create,  Topic.seq_qos   Topic.set_qos   Topic.set_qos   Subscriber.create_datareader   Discovery.dicover_datareader   Topic.read,  Topic.set_reader_qos   DataReader.set_qos   Discovery.change_datareader_qos   Topic.set_reader_qos   Publisher.create_datawriter   Discovery.dicover_datawriter   Topic.write,  Topic.set_writer_qos   DataWriter.set_qos   Discovery.change_datawriter_qos   Topic.set_writer_qos   DataWriter.register_instance   DataWriter.write   Protocol.receive_instance_new   Topic.create_instance   DataWriter.dispose   Protocol.receive_dispose   Topic.dispose_instance   MR#  6.5.1  
  28. 28. DDS  &  RTPS  Support  for  Security   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   28  
  29. 29. Support  for  Security  in  DDS  &  RTPS   •  DDS  ParTcipants  need  to  exchange  security  informaTon   –  CerTficates  for  AuthenTcaTon  &  Permissions   –  Handshake  messages  for  mutual  authenTcaTon  and  shared-­‐ secret  establishment   –  KeyTokens  for  key-­‐exchange   •  Some  reuse  of  exisTng  DDS  mechanisms   –  Discovery  topics   –  BuilTn  data  readers  /  writers   •  AddiTon  of  a  InterparTcipantStatelessWriter/Reader   •  EncrypTon  and  signatures  introduce  new  RTPS   Submessage  and  Submessage  elements   –  SecureSubMessage   –  SecuredData   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   29  
  30. 30. Extensions  to  BuilTnTopics   •  DCPSParTcipants:   – AddiTonal  members:   idenTty_token  :          IdenTtyToken                    (PID    0x1001)     permissions_token  :    PermissionsToken      (PID    0x1002)   •  DCPSPublicaTons  and  DCPSSubscripTons:   – AddiTonal  member:   data_tags  :                      DataTag  (PID    0x1003)     struct  Tag  {    string  name;    string  value;   };   struct  DataTags  {    sequence<Tag>;   };   struct DataHolder { string classid; StringMap properties; OctetsMap properties; StringSeq strings_value; OctetSeq binary_value1; OctetSeq binary_value2; LongLongSeq longlongs_value; };    //@Extensibility   MUTABLE_EXTENSIBILITY   struct Token DataHolder ; typedef <XXX>Token Token; Changed  
  31. 31. InterParTcipantStateless  channel   •  Inherent  “sequence  number”  vulnerability  with  any   stateful  channel.     –  Send  a  Heartbeat  for  a  future  sequence  number  effecTvely   shuts  down  channel   •  Well-­‐known  in  TCP.    But  miTgated  via:   –  Random  start  sequence  number  per  session   –  RejecTon  of  sequence  numbers  outside  window   These  “works”  for  TCP  because  it  is  point-­‐to-­‐point  and  is  not   communicaTng  state  (so  no  GAPs).  It  would  not  work  for   discovery,  using  mulTcast,  etc.   To  be  robust  to  this  aVack  you  need  a  protocol  that  does   not  reject  things  based  on  sequence  numbers   This  is  already  supported  in  the  RTPS  specificaTon   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   31  
  32. 32. InterParTcipant  Stateless  channel   •  InterparTcipantStatelessWriter  and   InterparTcipantStatelessReader   •  InterparTcipantStatelessGenericMessage   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   32   struct  MessageIdenTty  {    octet            source_guid[16];    long  long    sequence_number;   };   typedef  string<>  GenericMessageClassId;   struct  InterParTcipantStatelessGenericMessage  {                  //  target  for  the  request.  Can  be  GUID_UNKNOWN    BuilTnTopicKey_t  des5na5on_par5cipant_key;      MessageIdenTty  messageIdenTty;    MessageIdenTty  relatedMessageIdenTty;    GenericMessageClassId  msgClassid;    DataHolder msgData;  //@shared   };  //@Extensibility  MUTABLE_EXTENSIBILITY   Uses  the  RTPS  stateless   writers  and  readers   RTPS  v.  2.1  SecTon  8.4.7.2   and  8.4.10.2  
  33. 33. Security  informaTon  exchanged  via   InterParTcipantStatelessWriter/Reader   Behavior:     RTPS  v  2.1  stateless  writer/rdr   (secTon  8.4.7.2  &  8.4.10.2)   •  Does  not  reject  messages   based  on  sequence  number   •  Robust  against  sequence   number  aVack   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   33   struct  MessageIdenTty  {    octet            source_guid[16];    long  long    sequence_number;   };   typedef  string<>  GenericMessageClassId;   struct  InterParTcipantStatelessGenericMessage  {                  //  target.  Can  be  GUID_UNKNOWN    BuilTnTopicKey_t  des5na5on_par5cipant_key;      MessageIdenTty  message_idenTty;    MessageIdenTty  related_message_idenTty;    GenericMessageClassId  message_classid;    DataHolder  message_data;    //@shared   };  //@Extensibility  MUTABLE_EXTENSIBILITY   Changed   4  message  kinds:   GMCLASSID_SECURITY_AUTH_HANDSHAKE   GMCLASSID_SECURITY_PARTICIPANT_CRYPTO_TOKENS   GMCLASSID_SECURITY_DATAWRITER_CRYPTO_TOKENS   GMCLASSID_SECURITY_DATAREADER_CRYPTO_TOKENS  
  34. 34. Security  informaTon  exchanged  via   InterParTcipantStateless  Writer/Reader   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   34   struct  CryptoTokensMsg  {          octet  sending_guid[16];          octet  receiving_guid[16];          sequence<CryptoToken>  crypto_tokens;   };   typedef  Token  HandshakeTokenMsg;   typedef  CryptoTokensMsg    Par5cipantCryptoTokensMsg;   typedef  CryptoTokensMsg    DatawriterCryptoTokensMsg;   typedef  CryptoTokensMsg    DatareaderCryptoTokensMsg;   4  message  kinds:   GMCLASSID_SECURITY_AUTH_HANDSHAKE   GMCLASSID_SECURITY_PARTICIPANT_CRYPTO_TOKENS   GMCLASSID_SECURITY_DATAWRITER_CRYPTO_TOKENS   GMCLASSID_SECURITY_DATAREADER_CRYPTO_TOKENS  
  35. 35. Protocol-­‐level  support   Background:  RTPS   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   35   RTPS  SubMessage   RTPS  Header   RTPS  SubMessage   RTPS  SubMessage   RTPS  SubMessage   SubMsg  Header   SubMsg  Element   SubMsg  Element   SerializedData   RTPS  SubMessage   RTPS  Message  
  36. 36. Cryptographic  SPI  at  the  wire-­‐protocol  level   ©  2012  RTI  •  UNCLASSIFIED  •  PROPRIETARY   RTPS  SubMessage   SerializedData   RTPS  SubMessage   SerializedData   RTPS  Header   RTPS  Header   RTPS  SubMessage  (*)   RTPS  SubMessage   SecuredData   SerializedData   RTPS  SubMessage   SecuredData   SerializedData   RTPS  SubMessage  (*)   RTPS  SubMessage  (*)   Secure  encoding   Secure  decoding   Message  TransformaTon  
  37. 37. Security  Plugin  Architecture   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   37  
  38. 38. Plasorm  Independent  IntercepTon  Pts  +    SPIs     10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   38   Service Plugin Purpose Interactions Authentication Authenticate the principal that is joining a DDS Domain. Handshake and establish shared secret between participants The principal may be an application/process or the user associated with that application or process. Participants may messages to do mutual authentication and establish shared secret Access Control Decide whether a principal is allowed to perform a protected operation. Protected operations include joining a specific DDS domain, creating a Topic, reading a Topic, writing a Topic, etc. Cryptography Perform the encryption and decryption operations. Create & Exchange Keys. Compute digests, compute and verify Message Authentication Codes. Sign and verify signatures of messages. Invoked by DDS middleware to encrypt data compute and verify MAC, compute & verify Digital Signatures Logging Log all security relevant events Invoked by middleware to log Data Tagging Add a data tag for each data sample MR#  6.5.2  
  39. 39. Plasorm  Independent  SPIs     10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   39   MR#  6.5.2  
  40. 40. BuilTn  Plugins   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   40   SPI   Buil5n  Plungin   Notes   AuthenTcaTon   DDS:Auth:PKI-­‐RSA/DSA-­‐DH     Uses  PKI  with  a  pre-­‐configured  shared   CerTficate  Authority.   DSA  and  Diffie-­‐Hellman  for  authenTcaTon   and  key  exchange   Establishes  shared  secret   AccessControl   DDS:Access:PKI-­‐Signed-­‐ XML-­‐Permissions     Permissions  document  signed  by  shared   CerTficate  Authority   Cryptography   DDS:Crypto:AES-­‐CTR-­‐ HMAC-­‐RSA/DSA-­‐DH     Protected  key  distribuTon   AES128  and  AES256    for  encrypTon  (in   counter  mode)   SHA1  and  SHA256  for  digest   HMAC-­‐SHA1  and  HMAC-­‐256  for  MAC   DataTagging   Discovered_EndpointTags   Send  Tags  via  Endpoint  Discovery   Logging   DedicatedDDS_LogTopic   MR#  6.5.3  
  41. 41. Mapping  to  DDS  Language  PSMs     •  Plugin  SPIs  to  be  defined  using  IDL   •  IDL-­‐to-­‐Language  mappings  used  for  each   Language  PSM   •  No  need  to  define  mappings  to  new  Javs5   PSM  and  STD-­‐C++  PSM   – IDL-­‐derived  Language  PSMs  suffice  as  these  are   low-­‐level  interfaces  that  will  only  be  exercised  by   SPI  plugin  implementers.   NOTE:  IDL  file  is  missing  from  submission   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   41   MR#  6.5.4  
  42. 42. AuthenTcaTon   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   42  
  43. 43. AuthenTcaTon  SPI   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   43   MR#  6.5.2  
  44. 44. Full  AuthenTcaTon  SPI   •  validate_local_idenTty   •  get_idenTty_token   •  set_permissions_credenTal_and_token   •  validate_remote_idenTty   •  begin_handshake_request   •  begin_handshake_reply   •  process_handshake   •  get_shared_secret   •  get_peer_permissions_credenTal_token   •  set_listener   •  return_idenTty_token   •  return_peer_permissions_credenTal_token   •  return_handshake_handle   •  return_idenTty_handle   •  return_sharedsecret_handle   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   44  
  45. 45. AuthenTcaTon   Behavior  10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   45   MR#  6.5.2   Meta-­‐Protocol  to   handshake  and   establish  shared   secret  
  46. 46. BuilTn    DDS:Auth:PKI-­‐DSA-­‐DH     •  Uses  shared  CerTficate  Authority  (CA)   – All  ParTcipants  pre-­‐configured  with  shared-­‐CA   •  Performs  mutual  authenTcaTon  between   discovered  parTcipants  using  the  Digital   Signature  Algorithm  (DSA)     •  Establishes  a  shared    secret  using  Diffie-­‐ Hellman.   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   46  
  47. 47. ConfiguraTon  of  Auth:PKI-­‐DS-­‐DH   •  Three  things:   –  X.509  cerTficate  that  defines  the  shared  CA.  This   cerTficate  contains  the  Public  Key  of  the  CA.   –  RSA  private  key  of  the  DomainParTcipant.     –  A  (PEM-­‐encoded)  X.509  cerTficate  that  chains  up  to   the  CA,  that  binds  the  DomainParTcipant  public  key     to  the  disTnguished  name  (subject  name)  for  the   parTcipant  and  any  intermediate  CA  cerTficates   required  to  build  the  chain.     •  ConfiguraTon  API  outside  scope  of  specificaTon   –  Vendors  can  use  file,  QoS  property,  etc.   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   47  
  48. 48. Behavior  of  Auth:PKI-­‐DS-­‐DH   •  validate_local_parTcipant   –  IdenTtyCredenTalToken  has  X.509  cerTficate     –  Validates  cerTficate  against  CA   •  begin_handshake_request   –  Sends  X.509  CerTficate  to  peer  parTcipant   –  Sends  Signed  Permissions  to  to  peer  parTcipant   –  Sends  Challenge   •  begin_handshake_reply   –  Sends  X.509  CerTficate  to  peer  parTcipant   –  Sends  Signed  Permissions  to  to  peer  parTcipant   –  Replies  to  Challenge  &  sends  counter  Challenge   •  process_handshake   –  Verifies  challenge  response   –  Responds  to  final  challenge   –  Exchanges  SharedSecret   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   48  
  49. 49. 10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   49   Remote  ParTcipant  AuthenTcaTon   ParTcipants  receive  Hash(X.509  IdenTtyCert)    &  Hash   (Permissions  Doc)  of  remote  parTcipant  via  discovery  
  50. 50. 10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   50   Each  ParTcipant  calls  validate_remote_idenTty().   ParTcipant  with  highest  GUID  returns   PENDING_HANDSHAKE_REQUEST,  the  other   PENDING_HANDSAHKE_MESSAGE   Remote  ParTcipant  AuthenTcaTon  
  51. 51. 10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   51   ParTcipant1  creates  CHALLENGE1  =  “CHALLENGE:<nonce>   and  sends  message  via  ParTcipantMessageWriter  with   HanshakeMessageToken  :=  {CHALLENGE1,  IdenTty,   Permissions}   Remote  ParTcipant  AuthenTcaTon  
  52. 52. 10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   52   ParTcipant2  validates  IdenTty  of  ParTcipant1  against  CA   ParTcipant2  creates  CHALLENGE2  :=  CHALLENGE:<nonce>   ParTcipant2    sends  to  ParTcipant1  message  with     MessageToken  :=  {SIGN(CHALLENGE1),  CHALLENGE2,   IdenTty,  Permissions}   Remote  ParTcipant  AuthenTcaTon  
  53. 53. 10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   53   Part1  validates  IdenTty  of  ParTcipant2  against  CA   Part1  verifies  SIGN(CHALLENGE1)  using  ParTcipant2’s  PK   Part1    computes  a  SharedSecret   Part1  sends  message  with  contents:   MessageToken          :=  {  ENCRYPT(SharedSecret),                        SIGN(  HASH(CHALLENGE2  #  ENCRYPT(SharedSecret)))    }   Encrypt  uses  Part2’s  PK.   Remote  ParTcipant  AuthenTcaTon  
  54. 54. 10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   54   Part2  verifies  SIGN(  HASH(CHALLENGE2  #  ENCRYPT(SharedSecret))) using  Part1’s  PK   Part2    decrypts  ENCRYPT(SharedSecret)  using  its  own  PK   We  have  Mutual  Authen5ca5on  and  a  SharedSecret   Remote  ParTcipant  AuthenTcaTon  
  55. 55. Access  Control   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   55  
  56. 56. Access  Control  SPI   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   56   MR#  6.5.2  
  57. 57. Full  AccessControl  SPI   •  check_create_parTcipant   •  check_create_datawriter   •  check_create_datareader   •  check_create_topic   •  check_local_datawriter_register_instance   •  check_local_datawriter_dispose_instance   •  check_remote_parTcipant   •  check_remote_datawriter   •  check_remote_datareader   •  check_remote_topic   •  check_local_datawriter_match   •  check_local_datareader_match   •  check_remote_datawriter_register_instance   •  check_remote_datawriter_dispose_instance   •  get_permissions_token   •  get_permissions_credenTal_token   •  set_listener   •  return_permissions_token   •  return_permissions_credenTal_token   •  validate_local_permissions   •  validate_remote_permissions   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   57  
  58. 58. Support  for  AccessControl  on  data-­‐tags   and  parTTons   •  check_local_datawriter_match   •  check_local_datareader_match   – OperaTons  receive  the  reader  &  writer  Permissions   Handles  and  DataTags   •  The  PermissionsHandles  can  cache  any  QoS  that  is  relevant   to  access  control  decisions   Supports  AccessControl  rules  based  on  DataTags  or   matching  of  other  writer/reader  aVributes  (e.g.   based  on  parTTon  names)   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   58  
  59. 59. BuilTn    DDS:AC:PKI    SPI   •  Configured  with:   –  X.509  CerTficate  of  shared  Permissions  CA   –  PermissionsCredenTalToken   •  PermissionsCredenTalToken  contains   –  XML  file  with  permissions   –  Includes  SubjectName  matching  the  one  on   IdenTtyCredenTalToken   –  All  signed  by  Permissions  CA     –  FormaXed  as  PKCS#7  document  of  type  signed  data   This  binds  the  permissions  to  the  idenTty  established  by   the  AuthenTcaTonPlugin   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   59  
  60. 60. Example  Permissions   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   60  
  61. 61. Cryptographic   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   61  
  62. 62. 10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   62   Cryptographic  
  63. 63. Full  Cryptographic  SPI  (CryptoKeyFactory)   •  register_local_parTcipant   •  register_matched_remote_parTcipant   •  register_local_datawriter   •  register_matched_remote_datareader   •  register_local_datareader   •  register_matched_remote_datawriter   •  unregister_parTcipant     •  unregister_datawriter   •  unregister_datareader     10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   63  
  64. 64. Full  Cryptographic  SPI  (CryptoKeyExchnage)   •  encode_serialized_data   •  encode_datawriter_submessage   •  encode_datareader_submessage   •  encode_rtps_message   •  decode_rtps_message   •  preprocess_secure_submsg   •  decode_datawriter_submessage   •  decode_datareader_submessage   •  decode_serialized_data   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   64  
  65. 65. Full  Cryptographic  SPI  (CryptoTransform)   •  register_local_parTcipant   •  register_matched_remote_parTcipant   •  register_local_datawriter   •  register_matched_remote_datareader   •  register_local_datareader   •  register_matched_remote_datawriter   •  unregister_parTcipant     •  unregister_datawriter   •  unregister_datareader     10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   65  
  66. 66. RTPS  SubMessage   SerializedData   RTPS  Header   RTPS  Header   RTPS  SubMessage   SecuredData   SerializedData   encode_serialized_data   RTPS  SubMessage   RTPS  SubMessage  
  67. 67. RTPS  SubMessage   RTPS  Header   encode_datawriter_submessage   RTPS  Header   RTPS  SecureSubMsg   RTPS  SubMessage   RTPS  SubMessage   RTPS  SubMessage   RTPS  SubMessage   RTPS  Header   encode_datareader_submessage   RTPS  Header   RTPS  SecureSubMsg   RTPS  SubMessage   RTPS  SubMessage   RTPS  SubMessage  
  68. 68. RTPS  SubMessage   RTPS  SubMessage   RTPS  Header   RTPS  Header   RTPS  SecureSubMsg   encode_rtps_message   RTPS  SubMessage   RTPS  SubMessage   RTPS  SubMessage   RTPS  SubMessage  
  69. 69. RTPS  SubMessage   SerializedData   RTPS  SubMessage   SerializedData   RTPS  Header   RTPS  Header   RTPS  SecSubMsg   RTPS  SubMessage   SecuredData   SerializedData   RTPS  SubMessage   SecuredData   SerializedData   RTPS  SecSubMsg   RTPS  SecSubMsg   encode_rtps_message   encode_datawriter_submessage   encode_serialized_data  
  70. 70. Crypto-­‐AES-­‐CTR-­‐HMAC-­‐DSA-­‐DH   •  EncrypTon  uses  AES  in  counter  mode   –  Similar  to  SRTP,  but  enhanced  to  support  mulTple   topics  within  a  single  RTPS  message  and   infrastructure  services  like  a  relay  or  persistence   •  Use  of  counter  mode  turns  the  AES  block  cipher   into  a  stream  cipher   –  Each  DDS  sample  is  separately  encrypted  and  can  be   decrypted  without  process  the  previous  message   •  This  is  criTcal  to  support  DDS  QoS  like  history,  content   filters,  best-­‐efforts  etc.   •  DSA  and  Diffie-­‐Hellman  used  for  mutual   authenTcaTon  and  secure  key  exchange   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   70   MR#  6.5.3  
  71. 71. BuilTn    DDS:Crypto-­‐AES-­‐CTR-­‐HMAC-­‐DSA-­‐ DH  SPI   •  Shared  secret  used  to  create  a  KeyExchangeKey   •  KeyExchangeKey  used  to  send  following  Master  Key  Material  using  the   BuilTnPublicaTonWriter:   –  MasterKey   –  MasterSalt   –  MasterHMACSalt   •  Based  on  this  the  following  Key  Material  is  computed:   –  SessionSalt  :=  HMAC(MasterKey,"SessionSalt"  +  MasterSalt  +  SessionId  +  0x00)        [  Truncated  to  128  bits]   –  SessionKey  :=  HMAC(MasterKey,"SessionKey"  +  MasterSalt  +  SessionId  +  0x01)   –  SessionHMACKey  :=  HMAC(MasterKey,"SessionHMACKey"  +  MasterHMACSalt  +  SessionId)   Note:  SessionId  goes  on  the  EncryptedMessage  Envelope   •  EncrypTon  uses  AES  in  Counter  (CTR)  mode   –  The  session  counter  is  sent  on  EncryptedMessage  Envelope.   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   71  
  72. 72. Data  Tagging   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   72  
  73. 73. DataTagging:  DDS:Tagging:DDS_Discovery     •  DataWriter  and  DataReader  enTTes  have   associated  tags   •  DataWriter  Tags  are  propagated  via  DDS  discovery   •  AccessControl  plugin  has  visibility  into  tags  and   can  make  decisions  based  on  that   •  BuilTn  plugins   –  AccessControl  plugin  ignores  tags   –  Permissions  document  format  does  not  allow  rules   based  on  data-­‐tags   –  Rules  can  be  added  when  use-­‐case  is  beVer   understood   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   73  
  74. 74. Data  Logging   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   74  
  75. 75. DataLogging:  DDS:Logging:DDS_LogTopic     [SecTon  sTll  missing]   •  Intent  is  to  use  a  dedicated  DDS  Topic  to  Log   the  security-­‐relevant  messages   •  DDS  Secure  Log  Topic  will  be  encrypted     10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   75  
  76. 76. Status  &  Conclusions   •  We  feel  specificaTon  will  be  ready  to  adopt  in   December   •  Tasks/Missing  items   –  Update  UML  with  added  operaTons   –  Complete  secTons  7.2.3  and  7.2.4  (extra  details  on  how  RTPS   is  affected)   –  Add  descripTon  on  how  discovery  traffic  is  secured  (Kx  for   builTn  topics)   –  Add  descripTon  of  the  built-­‐in  Logging  plugin   –  Review  document  for  grammar   10/9/13   ©  2012  Real-­‐Time  InnovaTons,  Inc.    -­‐    All  rights  reserved   76  
  77. 77. Find  out  more…   www.rT.com   community.rT.com   demo.rT.com   www.youtube.com/realTmeinnovaTons   blogs.rT.com   www.twiVer.com/RealTimeInnov   www.facebook.com/RTIsoaware   www.slideshare.net/GerardoPardo   dds.omg.org   www.omg.org   ©  2012  RTI  •  ALL  RIGHTS  RESERVED   77  

×