OMG Data-Distribution Service Security
Upcoming SlideShare
Loading in...5
×
 

OMG Data-Distribution Service Security

on

  • 534 views

Overview of the OMG Distribution Service Security specification. Adopted by OMG in March 2014

Overview of the OMG Distribution Service Security specification. Adopted by OMG in March 2014

Statistics

Views

Total Views
534
Views on SlideShare
510
Embed Views
24

Actions

Likes
2
Downloads
9
Comments
0

2 Embeds 24

https://twitter.com 16
http://mangastorytelling.tistory.com 8

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

OMG Data-Distribution Service Security OMG Data-Distribution Service Security Presentation Transcript

  • Your  systems.  Working  as  one.   RTI  Technical  Update   Focus:  DDS  Security   Gerardo  Pardo-­‐Castellote,  Ph.D     CTO.  Real-­‐Time  Innova:ons  (RTI)   Prepared    February  2014  
  • Technical  Mee:ng  Agenda   • DDS  Background   • Security  Background   • DDS  Security  Specifica:on   • Discussion  &  Next  Steps   3  
  • DDS  Background   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   4  
  • Data-­‐Centric  Qos-­‐Aware  Pub-­‐Sub  Model   Persistence   Service   Recording   Service   Virtual,  decentralized  global  data  space   CRUD  opera:ons   Source (Key) Speed Power Phase WPT1 37.4 122.0 -12.20 WPT2 10.7 74.0 -12.23 WPTN 50.2 150.07 -11.98
  • Data   Reader   “Alarm”   Domain   Par:cipant   Data   Writer   “Alarm”   Domain   Par:cipant   Data-­‐Centric   Communica:ons  Model   •  ParDcipants  scope  the  global  data  space  (domain)   •  Topics  define  the  data-­‐objects  (collec:ons  of  subjects)   •  DataWriters  publish  data  on  Topics   •  DataReaders  subscribe  to  data  on  Topics   •  QoS  Policies  are  used  configure  the  system   •  Listeners  are  used  to  no:fy  the  applica:on  of  events   Listener   Offered QoS Listener   Got new data Requested QoS New subscriber ! example  
  • Data-­‐Object  Iden:ty  in  the  Global  Data  Space   •  Domain:  world  you’re  talking  about   •  Topic:  group  of  similar  objects   –  Similar  structure  (“type”)            what   –  Similar  way  they  change            when   over  :me  (“QoS”)                              how   •  Instance:  individual  object   –  Like  the  “key”  fields    in  a  database  table   •  DataWriter:  source  of  observa:ons  about  a  set   of  data-­‐objects  (Topic)   •  DataReader:  observer  of  a  set  of  data-­‐objects   (Topic)   Domain   (e.g.  Yellowstone  Park)   Topic   (e.g.  bears  in  the  park)   Topic   Snow  Depth  Sensors   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   ID   GPS   value   Instance   (e.g.  Yogi     the  bear)   Instance   Object  Address  ==  Object  Iden:ty  
  • Sample  Iden:fica:on  need   •  DataReaders  must  be  able  to  combine  the  samples   from  mul7ple  physical  data  sources  publishing  from   related  logical  data  source(s).   •  Example:  MulD-­‐Path  Delivery   •  Example:  Cross-­‐Topic  Ordering   8    DataReader   Durability  Service   DDS   Domain    “PosiDon”   DataReader   “PosiDon”   DataWriter   “Velocity” DataWriter DDS   Domain    “Velocity”   DataReader    Subscriber    Publisher  
  • Global  Sample  Iden:fica:on   Each  sample  within  a  Domain  and  a  Topic  is  uniquely  iden:fied  by  a   virtual  iden:ty:  the  tuple    (Virtual  GUID,  Virtual  SequenceNumber)   –  Virtual  GUID  (VGUID):            16-­‐byte  iden:fier  iden:fying  the  data  source.     –  Virtual  Sequence  Number  (VSN):          monotonically  increasing  64-­‐bit  integer  that  iden:fies  the   sample  in  the  data  source.   DataWriter   DataWriter   DataWriter   DataBus   Domain   DataReader   (1,1)   (1,1)   (1,1)   (1,1)   (2,1)   (2,1)   (1,1)   (2,1)   A  DataReader  only  delivers  a   single  copy  of  a  sample  to   the  applica:on.  Duplicates   are  filtered  out.   (2,1)   Sample  with  VGUID  2   and  VSN1  
  • Approaches  to  Sogware  Integra:on   App   App   App  App   App   App   Point-­‐to-­‐point   Not  maintainable:     -­‐   Number  of  interfaces  grows  as  Modules^2   -­‐   Add  hoc  integra:on  makes  reuse  difficult   -­‐   Addi:on  of  new  modules  affects  exis:ng  ones  
  • Approaches  to  Sogware  Integra:on   App   App   App  App   App   App   Point-­‐to-­‐point   App   App   App  App   App   App   Server/   Broker/   ESB   Inefficient,  not-­‐robust,  and  expensive:     -­‐   Centralized  server  becomes  boFleneck   -­‐   Server  or  server-­‐comm  failure  compromises  system   -­‐   Server  is  hard  to  deploy,  power,  hide  
  • Approaches  to  Sogware  Integra:on                                                    DDS    Data-­‐Centric  Bus   App   App   App   App   App   App   App   App   App  App   App   App   Point-­‐to-­‐point   App   App   App  App   App   App   Server/   Broker/   ESB   Superior  approach:     -­‐   Number  of  interfaces  can  be  constant  or  linear     -­‐   No  servers  =>  performance  &  availability   -­‐   Lower  cost  in  hardware  &  soMware  maintenance    
  • Architecture  to  maximize  Availability,   Performance  &  Scalability   •  RTI  Connext  DDS  operates  peer-­‐to-­‐peer,  without  brokers   •  RTI  Connext  DDS  uses  RTPS,  an  Advanced  Mul7-­‐Session   protocol  suppor7ng  Reliable  Mul7cast   RTI  Connext  DDS  Approach   RTPS   JMS   AMQP   ESBs   …   Others:  Broker-­‐based  middleware   13  ©  2010  Real-­‐Time  Innova:ons,  Inc.      
  • Security  Background   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   14  
  • Is  there  a  Conflict?   •  Security…   –  desires  to  restrict  communica:on  to  only  happen   between  authorized  subjects   –  requires  to  confiden:ality  so  that  only  communica:ng   subjects  see  the  informa:on   •  PubSub/DDS   –  alempts  to  create  a  ‘global  informa:on  space’  where   anybody  can  access  the  informa:on  it  needs   –  de-­‐couples  communica:ons  so  publishers  are   unaware  of  subscribers  and  vice-­‐versa   ©  2007,  Real-­‐Time  Innova:ons,  Inc.   15  
  • No  Conflict:     Security  in  the  Global  Informa:on  Space   •  Publishers  are  decoupled  from  subscribers  via  the   Global  Informa:on  Space   –  This  does  not  mean  loss  of  access  control  to  the   informa:on   –  It  means  that  the  Informa:on  Space  must  have  an   associated  security  model   •  DDS  can  use  standard  PKI  and  cryptographic   techniques  to  enforce  the  security  policies   •  The  situa:on  is  analogous  to  access  control   policies  in  a  file  system   ©  2007,  Real-­‐Time  Innova:ons,  Inc.   16   The  key  is  to  use  a  net-­‐centric  security  model!  
  • Security  Terms:  a  Safe-­‐Deposit  Box   •  Authen:ca:on:  The  bank  knows  who  you  are;  you   must  show  ID.   •  Access  Control:  The  bank  only  lets  those  on  an   access  list  into  your  box.   •  Confiden:ality:  You  are  alone  in  the  room  Nobody   can  see  the  contents  of  the  box.   •  Integrity:    The  box  is  sealed.  If  anybody  touches  it   you  will  know.   •  Non  repudia:on:  You  sign  when  you  come  in  and   out  so  you  can’t  claim  that  you  weren’t  there.   •  Availability:  The  bank  is  always  open.     1717
  • Threats   1.  Unauthorized  subscrip:on   2.  Unauthorized  publica:on   3.  Tampering  and  replay     4.  Unauthorized  access  to  data   by  infrastructure  services     3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   18   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  
  • Data-­‐centric/mul:cast  Insider  Threats     •  Two  insider  threats  affec:ng  (mul:cast)  data-­‐ centric  systems  are  of  unique  significance   1.  Reader  mis-­‐behaves  as  unauthorized  writer   An  applica:on  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     3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   19  
  • Reader  mis-­‐behaves  as  unauthorized   writer   •  Situa:on:   –  Alice  -­‐    creates  a  Crypto  Key  per  Topic/DataWriter   –  Alice  -­‐  shares  its  Key  with  all  intended  readers  as  needed  to  mul:cast   –  Mallory  –  is  an  authorized  reader  so  it  has  Alice’s  key   –  Mallory  –  behaves  maliciously  and  uses  Alice’s  key  to  create  fake  UDP  messages  puung   Alice’s  informa:on  (IP,  Port,  GUIDs,  etc.)  but  with  bad  data.   •  Implica:ons:   –  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  alack  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   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   20  
  • Session  Sequence  Number  Alack   •  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  alacker  can  spoof  a  packet  with  the  session  ID  and   Hearbeat/GAP  causing  the  DataReader  to  advance  the  session   sequence-­‐numbers  blocking  future  messages  recep:on   –  Alacker  only  needs  GUID  of  the  DataWriter  to  alack,  which   can  be  obtained  from  snooping  traffic.   –  Alack  can  be  used  to  prevent  the  Authen:ca:on  of  legi:mate   Par:cipants   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   21  
  • Squaung  Alack  on  GUID   •  Background:   –  DDS  DomainPar:cipants  are  iden:fied  by  unique  GUID,   Readers/Writers  derive  their  GUID  from  it.   –  GUID  used  to  uniquely  iden:fies  the  RTPS  sessions  and  the   loca:on  of  each  par:cipant   •  Vulnerability:   –  An  alacker  with  legit  Iden:ty  can  authen:cate  using  the    GUID   of  another  Par:cipant   –  Alacker  with  be  accepted  with  “cuckooed”  GUID  blocking   legi:mate  Par:cipant  from  using  its  GUID   –  Alacker  only  needs  GUID  of  the  Par:cipant  to  alack,  which   can  be  obtained  from  snooping  traffic.   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   22  
  • Fine-­‐Grained  Data-­‐Centric  Security   •  Access  control  per  Topic   •  Read  versus-­‐write  permissions   •  Field-­‐specific  permissions   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   23   Topics  
  • Three  security  boundaries   •  Boundary  security   •  Transport-­‐Level     – Network  (layer  3)  security   – Session  (layer  4/5)  security   •  Fine-­‐grained  Data-­‐Centric  Security   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   24   UlDmately  you  need  to  implement  the  3  of  them  
  • Secure  Data  Transfer   1.  Authen:cate   – Verify  your  iden:ty   2.  Securely  exchange  cryptographic  keys   3.  Use  keys  to:   – Encrypt  data   – Add  a  message  authen:ca:on  code     3/17/14   ©  2012  RTI  •  COMPANY  CONFIDENTIAL   25   App  1   App  2  
  • Transport  Layer  Security  (TLS)  for  DDS   • Provides   – Authen:ca:on  and  key  exchange   – Encryp:on  with  symmetric  keys   – Message  authen:ca:on   • Proven  and  widely  used   – Web  browsing,  email,  IM,  VoIP   – Client-­‐server   – Primarily  used  over  TCP  but  there  is  also  a   UDP  version  (DTLS)   3/17/14   ©  2012  RTI  •  COMPANY  CONFIDENTIAL   26  
  • Transport  Layer  Security  (TLS)  for  DDS   3/17/14   ©  2012  RTI  •  COMPANY  CONFIDENTIAL   27   TLS  Handshake   Protocol   TLS  Record  Protocol   TCP/IP   DDS   Applica:on  1   TLS  Handshake   Protocol   TLS  Record  Protocol   TCP/IP   DDS   Applica:on  1   PKI  Cer:ficate  Exchange,   Verifica:on,  Crea:on  of  Session  Keys   Encrypted,  &  Signed  Traffic   RTPS  Traffic   Secure  Discovery  and  Data   Exchange  
  • TLS/TCP  for  Real-­‐Time  Systems   •  DDS  typically  runs  over  UDP/IP   – Runs  in  best-­‐effort  mode  for  sensor  data   – Reliable  mode  –  tuned  for  real-­‐:me   •  Performance  challenges  with  TCP   – Latency  –  more  jiler  for  sensor  data,  generally   higher   – Throughput   3/17/14   ©  2012  RTI  •  COMPANY  CONFIDENTIAL   28  
  • 29 (D)TLS  Transport  for  DDS   •  DTLS:  Datagram  version  of  the  TLS  protocol   •  Like  TLS  provides:    AuthenDcaDon,  encrypDon,  integrity   •  Requires:   –  A  Cer:ficate  Authority  (CA)   –  An  applica:on  must  be  configured  with  an  iden:fying  cer:ficate   assigned  by  the  CA   –  An  applica:on  must  have  a  private  key  associated  with  the   public  key  in  the  cer:ficate   •  Standard  protocol  (  with  open  source:  OpenSSL  )   –  The  protocol  is  highly  scru:nized   –  No  mulDcast  support   This  transport  is  available  in   Connext  DDS  4.5  and  5.0  
  • DTLS  Performance  –  Latency   3/17/14  ©  2011  Real-­‐Time  Innova:ons,  Inc.    COMPANY  CONFIDENTIAL   30  
  • Secure  Transport-­‐Level  Solu:ons  for  DDS   • Scenarios:   1.  Connect  separate  real-­‐:me  systems   2.  Provide  a  secure  connec:on  into  a  real-­‐ :me  system   3.  Connect  LANs  over  an  non-­‐secured  WAN   3/17/14   ©  2012  RTI  •  COMPANY  CONFIDENTIAL   31   These  scenarios  are  supported  in   Connext  DDS  4.5  and  5.0  
  • 1.    Secure  Channel  between  Systems   3/17/14   32   System  1   Rou:ng   Service   Gateway  acts  as   security  point   System  2   Rou:ng   Service   TLS   This  solu7on  is  available  in   Connext  DDS  4.5  and  5.0  
  • Secure  Channel  with  Firewall   3/17/14   33   System  1   Rou:ng   Service   System  2   Rou:ng   Service   TLS   Can  use  firewall  as   added  protec:on   This  solu7on  is  available  in   Connext  DDS  4.5  and  5.0  
  • DDS  Rou:ng  Service  with  Secure  Asymmetric  TCP   •  WAN  clients  access  DDS  data  within  LAN   –  Clients  communicate  with  par:cipants  in  LAN  not  between  each  other   –  Clients  behind  fire-­‐walls   –  Only  one  public  address  required.  Only  one  firewall  configured   •  Example:  Exposing  a  service  to  end-­‐user  clients   Remote   App   System  1   Rou:ng   Service   Remote   App   Remote   App   This  solu7on  is  available  in   Connext  DDS  4.5  and  5.0   Assymetric  TLS  
  • 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   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   35   UlDmately  you  need  to  implement  the  3  of  them  
  • Secure  DDS  Specifica:on   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   36  
  • RPC     over  DDS   2014   DDS   Security   2014   Web-­‐Enabled   DDS   2013   Family  of  Specifica:ons   37   DDS   Implementa:on   Network  /  TCP  /  UDP  /  IP   App   DDS   Implementa:on   App   DDS   Implementa:on   DDS  Spec   2004   DDS   Interoperablity   2006   UML  Profile   for  DDS   2008   DDS  for   Lw  CCM   2009   DDS     X-­‐Types   2010   2012   DDS-­‐STD-­‐C++   DDS-­‐JAVA5   App   37  ©  2012  RTI  •  ALL  RIGHTS  RESERVED  
  • DDS  Security  covers  4  related  concerns   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   38   Security  Plugin   APIs  &  Behavior   DDS  &  RTPS  support   for  Security   BuilDn  Plugins   Security  Model  
  • Secure  DDS  Specifica:on:   Security  Model   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   39  
  • Security  Model   •  A  security  model  is  defined  in  terms  of:   – The  subjects  (principals)   – The  objects  being  protected   •  The  opera:ons  that  are  protected  on  the  objects   – Access  Control  Model   •  A  way  to  map  each  subject  to  the  objects  they  can   perform  opera:ons  on  and  which  are  the  allowed   opera:ons   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   40   MR#  6.5.1  
  • Security  Model  Example:   UNIX  FileSystem  (simplified)   •  Subjects:    Users,  specifically  processes  execu:ng  on  behalf  of  a  specific  userid   •  Protected  Objects:    Files  and  Directories   •  Protected  Opera:ons  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  combina:on  of  READ,  WRITE,  EXECUTE  permissions   for  the  assigned  OWNER  and  GROUP   –  Each  protected  opera:on  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   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   41  
  • DDS  Security  Model   •  Subjects:    DDS  DomainPar:cipant  (Par:cipant  GUID)   •  Protected  Objects:    DDS  Domain  and  DDS  Topic   •  Protected  OperaDons  on  Objects  (logical  view):   –  DomainPar:cipant.join   –  DomainPar:cipant.add_read_par::on   –  DomainPar:cipant.add_write_par::on   –  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   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   42   MR#  6.5.1  
  • Mapping  of  DDS  API  to  protected  opera:ons   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   43   DDS  API  Call     Protected  OperaDon   DomainPar:cipantFactory.create_par:cipant   Discovery.match_remote_par:cipant   DomainPar:cipant.join   DomainPar:cipant.create_publisher   Publisher.set_qos   DomainPar:cipant.add_write_par::on   DomainPar:cipant.create_subscriber   Subscriber.set_qos   DomainPar:cipant.add_read_par::on   DomainPar:cipant.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  
  • Secure  DDS  Specifica:on:   Security  Plugins   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   44  
  • Pluggable  Security  Architecture   ©  2012  RTI  •  UNCLASSIFIED  •  PROPRIETARY   App.   Other     DDS   System   Secure  DDS     middleware   Authen:ca:on   Plugin   Access  Control   Plugin   Cryptographic   Plugin      Secure  Kernel   Crypto   Module   (e.g.  TPM  )     Transport  (e.g.  UDP)   applica:on  component  cer:ficates   ? Data   cache   Protocol   Engine   Kernel   Policies   DDS  En::es   Network   Driver   ? Network   Encrypted  Data  TAG   Other     DDS   System   Other     DDS   System   App.  App.   Logging   Plugin   DataTagging   Plugin   MAC  
  • Pla€orm  Independent  SPIs     3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   46   MR#  6.5.2  
  • Pla€orm  Independent  Intercep:on  Pts  +    SPIs     3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   47   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  
  • Buil:n  Plugins   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   48   SPI   BuilDn  Plungin   Notes   Authen:ca:on   DDS:Auth:PKI-­‐RSA/DSA-­‐DH     Uses  PKI  with  a  pre-­‐configured  shared   Cer:ficate  Authority.   DSA  and  Diffie-­‐Hellman  for  authen:ca:on   and  key  exchange   Establishes  shared  secret   AccessControl   DDS:Access:PKI-­‐Signed-­‐ XML-­‐Permissions     Permissions  document  signed  by  shared   Cer:ficate  Authority   Cryptography   DDS:Crypto:AES-­‐CTR-­‐ HMAC-­‐RSA/DSA-­‐DH     Protected  key  distribu:on   AES128  and  AES256    for  encryp:on  (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  
  • DDS  Flow   3/17/14   ©  2012  RTI  •  UNCLASSIFIED  •  PROPRIETARY   49   Create   Domain   Par:cipant     Authen:cate   DP?   Create   Endpoints   Discover   remote   Endpoints   Send/ Receive  data   Discover   remote  DP  
  • DDS  Security  Flow   3/17/14   ©  2012  RTI  •  UNCLASSIFIED  •  PROPRIETARY   50   Create   Domain   Par:cipant     Authen:cate   DP?   Create   Endpoints   Discover   remote   Endpoints   Send/ Receive  data   Discover   remote  DP   Authen:cate   DP?   Yes   Domain   Par:cipant   Create  Fails   No   Access  OK?   Endpoint   Create  Fails   No   Authen:cate   Remote  DP?   Ignore   Remote  DP   No   Yes   Access  OK?   Ignore   remote   endpoint   Message   security  
  • DDS  Security  Flow:  Access  Control   3/17/14   ©  2012  RTI  •  UNCLASSIFIED  •  PROPRIETARY   51   Create   Domain   Par:cipant     Authen:cate   DP?   Create   Endpoints   Discover   remote   Endpoints   Send/ Receive  data   Discover   remote  DP   Authen:cate   DP?   Yes   Domain   Par:cipant   Create  Fails   No   Access  OK?   Endpoint   Create  Fails   No   Authen:cate   Remote  DP?   Ignore   Remote  DP   No   Yes   Access  OK?   Ignore   remote   endpoint   Message   security  
  • DDS  Security  Flow  –  Remote  Authen:ca:on   3/17/14   ©  2012  RTI  •  UNCLASSIFIED  •  PROPRIETARY   52   Discover   remote   Endpoints   Discover   remote  DP   Authen:cate   Remote  DP?   Ignore   Remote  DP   No   Yes   Access  OK?   Ignore   remote   endpoint   Receive  Auth   Token   No   Matched  DW?   Get  Keys   Get  remote   DW  tag   Yes   Yes   Does  the   remote  Data   Writer  match   a  local  Data   Reader  
  • Secure  DDS  Specifica:on:   Authen:ca:on  Plugin   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   53  
  • Authen:ca:on  SPI   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   54   MR#  6.5.2  
  • Authen:ca:on   Behavior  3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   55   MR#  6.5.2   Meta-­‐Protocol  to   handshake  and   establish  shared   secret  
  • Buil:n    DDS:Auth:PKI-­‐DSA-­‐DH     •  Uses  shared  Cer:ficate  Authority  (CA)   – All  Par:cipants  pre-­‐configured  with  shared-­‐CA   •  Performs  mutual  authen:ca:on  between   discovered  par:cipants  using  the  Digital   Signature  Algorithm  (DSA)     •  Establishes  a  shared    secret  using  Diffie-­‐Hellman.   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   56  
  • Configura:on  of  Auth:PKI-­‐DS-­‐DH   •  Three  things:   –  X.509  cer:ficate  that  defines  the  shared  CA.  This   cer:ficate  contains  the  Public  Key  of  the  CA.   –  RSA  private  key  of  the  DomainPar:cipant.     –  A  (PEM-­‐encoded)  X.509  Iden:tyCer:ficate     •  Chains  up  to  the  CA,     •  Binds    PublicKey    to  the  dis:nguished  name  (subject  name)   for  the  DomainPar:cipant   •  Configura:on  API  outside  scope  of  specifica:on   –  Vendors  can  use  file,  QoS  property,  etc.   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   57  
  • Behavior  of  Auth:PKI-­‐DS-­‐DH   •  validate_local_par:cipant   –  Iden:tyCreden:alToken  has  X.509  cer:ficate     –  Validates  cer:ficate  against  CA   •  begin_handshake_request   –  Sends  X.509  Cer:ficate  to  peer  par:cipant   –  Sends  Signed  Permissions  to  to  peer  par:cipant   –  Sends  Challenge   •  begin_handshake_reply   –  Sends  X.509  Cer:ficate  to  peer  par:cipant   –  Sends  Signed  Permissions  to  to  peer  par:cipant   –  Replies  to  Challenge  &  sends  counter  Challenge   •  process_handshake   –  Verifies  challenge  response   –  Responds  to  final  challenge   –  Exchanges  SharedSecret   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   58  
  • 3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   59   Remote  Par:cipant  Authen:ca:on   Par:cipants  receive  Hash(X.509  Iden:tyCert)    &  Hash   (Permissions  Doc)  of  remote  par:cipant  via  discovery  
  • 3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   60   Each  Par:cipant  calls  validate_remote_iden:ty().   Par:cipant  with  highest  GUID  returns   PENDING_HANDSHAKE_REQUEST,  the  other   PENDING_HANDSAHKE_MESSAGE   Remote  Par:cipant  Authen:ca:on  
  • 3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   61   Par:cipant1  creates  CHALLENGE1  =  “CHALLENGE:<nonce>   and  sends  message  via  Par:cipantMessageWriter  with   HanshakeMessageToken  :=  {CHALLENGE1,  Iden:ty,   Permissions}   Remote  Par:cipant  Authen:ca:on  
  • 3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   62   Par:cipant2  validates  Iden:ty  of  Par:cipant1  against  CA   Par:cipant2  creates  CHALLENGE2  :=  CHALLENGE:<nonce>   Par:cipant2    sends  to  Par:cipant1  message  with     MessageToken  :=  {SIGN(CHALLENGE1),  CHALLENGE2,   Iden:ty,  Permissions}   Remote  Par:cipant  Authen:ca:on  
  • 3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   63   Part1  validates  Iden:ty  of  Par:cipant2  against  CA   Part1  verifies  SIGN(CHALLENGE1)  using  Par:cipant2’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  Par:cipant  Authen:ca:on  
  • 3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   64   Part2  verifies  SIGN(  HASH(CHALLENGE2  #   ENCRYPT(SharedSecret)))using  Part1’s  PK   Part2    decrypts  ENCRYPT(SharedSecret)  using  its  own  PK   We  have  Mutual  AuthenDcaDon  and  a  SharedSecret   Remote  Par:cipant  Authen:ca:on  
  • Secure  DDS  Specifica:on:   Access  Control  Plugin   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   65  
  • Access  Control  SPI   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   66   MR#  6.5.2  
  • Full  AccessControl  SPI   •  check_create_par:cipant   •  check_create_datawriter   •  check_create_datareader   •  check_create_topic   •  check_local_datawriter_register_instance   •  check_local_datawriter_dispose_instance   •  check_remote_par:cipant   •  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_creden:al_token   •  set_listener   •  return_permissions_token   •  return_permissions_creden:al_token   •  validate_local_permissions   •  validate_remote_permissions   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   67  
  • Support  for  AccessControl  on  data-­‐tags  and   par::ons   •  check_local_datawriter_match   •  check_local_datareader_match   – Opera:ons  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  alributes  (e.g.   based  on  par::on  names)   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   68  
  • Buil:n    DDS:AC:PKI    SPI   •  Configured  with:   –  X.509  Cer:ficate  of  shared  Permissions  CA   –  The  Domain  governance  signed  by  the  Permissions  CA   –  The  DomainPar:cipant  permissions  signed  by  the  Permissions  CA   •  The  Domain  governance  configures   –  Which  topics  shall  be  secured  and  how   –  Whether  discovery  is  secured  and  how   •  DomainPar:cipant  permissions   –  Specifies  what  Domains  Id  can  be  joined  by  the  DomainPar:cipant   –  Specified  which  Topics  and  be  Read/Wrilen  by  the  DomainPar:cipant  on   each  DomainId   –  Ties  to  the    SubjectName  matching  the  one  on  Iden:tyCer:ficate   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   69  
  • Example  Domain  Governance  
  • Example  Permissions  
  • Secure  DDS  Specifica:on:   Cryptographic  Plugin   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   72  
  • Cryptographic  SPI   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   73  
  • Full  Cryptographic  SPI  (CryptoKeyFactory)   •  register_local_par:cipant   •  register_matched_remote_par:cipant   •  register_local_datawriter   •  register_matched_remote_datareader   •  register_local_datareader   •  register_matched_remote_datawriter   •  unregister_par:cipant     •  unregister_datawriter   •  unregister_datareader     3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   74  
  • 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   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   75  
  • Full  Cryptographic  SPI  (CryptoTransform)   •  register_local_par:cipant   •  register_matched_remote_par:cipant   •  register_local_datawriter   •  register_matched_remote_datareader   •  register_local_datareader   •  register_matched_remote_datawriter   •  unregister_par:cipant     •  unregister_datawriter   •  unregister_datareader     3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   76  
  • Background:  RTPS   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   77   RTPS  SubMessage   RTPS  Header   RTPS  SubMessage   RTPS  SubMessage   RTPS  SubMessage   SubMsg  Header   SubMsg  Element   SubMsg  Element   SerializedData   RTPS  SubMessage   RTPS  Message  
  • 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   The  Cryptographic  plugin  implementa:on  &   configura:on  determines  which   transforma:ons  should  occur.  For  example   encrypt  only  some  topics.  HMAC  only  the   whole  RTPS  message,  etc.  
  • RTPS  SubMessage   SerializedData   RTPS  Header   RTPS  Header   RTPS  SubMessage   SecuredData   SerializedData   encode_serialized_data   RTPS  SubMessage   RTPS  SubMessage  
  • 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  
  • RTPS  SubMessage   RTPS  SubMessage   RTPS  Header   RTPS  Header   RTPS  SecureSubMsg   encode_rtps_message   RTPS  SubMessage   RTPS  SubMessage   RTPS  SubMessage   RTPS  SubMessage  
  • 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  Transforma:on  
  • Crypto-­‐AES-­‐CTR-­‐HMAC-­‐DSA-­‐DH   •  Encryp:on  uses  AES  in  counter  mode   –  Similar  to  SRTP,  but  enhanced  to  support  mul:ple   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  cri:cal  to  support  DDS  QoS  like  history,  content  filters,   best-­‐efforts  etc.   •  DSA  and  Diffie-­‐Hellman  used  for  mutual   authen:ca:on  and  secure  key  exchange   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   83   MR#  6.5.3  
  • Buil:n    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   Buil:nPublica:onWriter:   –  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   •  Encryp:on  uses  AES  in  Counter  (CTR)  mode   –  The  session  counter  is  sent  on  EncryptedMessage  Envelope.   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   84  
  • Data  Tagging   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   85  
  • DataTagging:  DDS:Tagging:DDS_Discovery     •  DataWriter  and  DataReader  en::es  have   associated  tags   •  DataWriter  Tags  are  propagated  via  DDS  discovery   •  AccessControl  plugin  has  visibility  into  tags  and   can  make  decisions  based  on  that   •  Buil:n  plugins   –  AccessControl  plugin  ignores  tags   –  Permissions  document  format  does  not  allow  rules   based  on  data-­‐tags   –  Rules  can  be  added  when  use-­‐case  is  beler   understood   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   86  
  • Data  Logging   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   87  
  • DataLogging:  DDS:Logging:DDS_LogTopic     [Sec:on  s:ll  missing]   •  Intent  is  to  use  a  dedicated  DDS  Topic  to  Log   the  security-­‐relevant  messages   •  DDS  Secure  Log  Topic  will  be  encrypted     3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   88  
  • Status  &  Conclusions   •  The  specifica:on  is  likely  to  be  adopted  in  March  2014   •  This  specifica:on  provides  a  framework  for  securing   DDS  systems.  The  buil:n  plugins  provide  a  “common”   approach  for  applica:ons  without  specialized   requirements   –  It  is  expected  that  plugins  will  be  developed  to  match  more  specialized   deployments  and  integrate  with  exis:ng  infrastructure.   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   89  
  • Discussion   3/17/14   ©  2012  Real-­‐Time  Innova:ons,  Inc.    -­‐    All  rights  reserved   90  
  • Your  systems.  Working  as  one.   Discussion  &  Next  Steps  
  • Find  out  more…   www.r:.com   community.r:.com   demo.r:.com   www.youtube.com/real:meinnova:ons   blogs.r:.com   www.twiler.com/RealTimeInnov   www.facebook.com/RTIsogware   www.slideshare.net/GerardoPardo   dds.omg.org   www.omg.org   ©  2012  RTI  •  ALL  RIGHTS  RESERVED   92