OMG DDS Security, 3rd revised submission
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

OMG DDS Security, 3rd revised submission

  • 2,403 views
Uploaded on

Third revised submission to the OMG Data Distribution Service Security Specification.

Third revised submission to the OMG Data Distribution Service Security Specification.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,403
On Slideshare
883
From Embeds
1,520
Number of Embeds
4

Actions

Shares
Downloads
16
Comments
0
Likes
0

Embeds 1,520

http://blogs.rti.com 1,506
http://newsblur.com 8
http://www.newsblur.com 5
http://feeds2.feedburner.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Your  systems.  Working  as  one.  DDS  SECURITY  3rd  Revised  Submission  dds/2012-­‐12-­‐12  Doc  num:  mars/2012-­‐12-­‐12   SubmiLers:  Presenter:   Real-­‐Time  InnovaKons,  Inc.  Gerardo  Pardo-­‐Castellote,  Ph.D.   PrismTech  Corp.  CTO,  Real-­‐Time  InnovaKons,  Inc.   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved  
  • 2. Agenda   •  Status  recap   •  Summary  of  submission   •  What  has  changed?   •  Some  details   •  Status  &  Conclusion  2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   2  
  • 3. Status  recap   •  Started  with  two  separate  submissions  by  RTI  and   PrismTech   –  RTI  submission  focused  on  the  mandatory  requirements  for   an  SPI  Architecture  and  built-­‐in  SPIs   –  PrismTech  focused  on  the  use  of  exisKng  technologies   (MIKEY  /  SRTP)  to  supports  the  needs  of  secure  DDS   •  RTI  took  AI  to  show  how  MIKEY  and  SRTP  could  be   supported  as  specific  SPIs  on  the  proposed  SPI   architecture  –  potenKally  could  lead  to  joint   submission   –  Basic  KeyExchange  and  EncrypKon  mechanisms  in  PT   submission  are  now  possible  in  the  built-­‐in  plugins   –  PrismTech  has  joined  the  submission  2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   3  
  • 4. Agenda   •  Status  recap   •  Summary  of  submission   •  What  has  changed?   •  How  the  submission  allows  a  specializaKon  to   use  MIKEY  and  SRTP   •  Status  &  Conclusion  2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   4  
  • 5. Security  as  a  system  problem   •  UlKmately  security  is  a  system  property   –  Involves  hardware,  soaware,  humans,   procedures…   •  Most  directly  related:  Scope  of   1.  Securing  the  data-­‐centric  bus  the  RFP   2.  IntegraKng  across  security  domains  Out   3.  Securing  the  operaKng  system  of  Scope   4.  Securing  the  hardware  &  soaware   configuraKon   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   5  
  • 6. Three  security  boundaries   Ul:mately  you  need  to  implement  the  3  of  them   •  Boundary  security   •  Transport-­‐Level     –  Network  (layer  3)  security   –  Session  (layer  4/5)  security   •  Fine-­‐grained  Data-­‐Centric   Security   Scope  of  the  DDS  Security  RFP  2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   6  
  • 7. Fine-­‐Grained  Data-­‐Centric  Security   Topics   •  Access  control  per  Topic   •  Read  versus-­‐write  permissions   •  Field-­‐specific  permissions  2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   7  
  • 8. Threats  Alice:  Allowed  to  publish  topic  T   1.  Unauthorized  subscripKon  Bob:  Allowed  to  subscribe  to  topic  T  Eve:  Non-­‐authorized  eavesdropper     2.  Unauthorized  publicaKon  Trudy:  Intruder   3.  Tampering  and  replay    Trent:  Trusted  infrastructure  service  Mallory:  Malicious  insider   4.  Unauthorized  access  to  data   by  infrastructure  services     2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   8  
  • 9. Data-­‐centric/mulKcast  Insider  Threats     •  Two  insider  threats  affecKng  (mulKcast)  data-­‐ centric  systems  are  of  unique  significance   1.  Reader  mis-­‐behaves  as  unauthorized  writer   An  applicaKon  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    2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   9  
  • 10. Reader  mis-­‐behaves  as  unauthorized   writer  •  SituaKon:   –  Alice  -­‐    creates  a  Crypto  Key  per  Topic/DataWriter   –  Alice  -­‐  shares  its  Key  with  all  intended  readers  as  needed  to  mulKcast   –  Mallory  –  is  an  authorized  reader  so  it  has  Alice’s  key   –  Mallory  –  behaves  maliciously  and  uses  Alice’s  key  to  create  fake  UDP  messages  pumng   Alice’s  informaKon  (IP,  Port,  GUIDs,  etc.)  but  with  bad  data.  •  ImplicaKons:   –  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   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   10  
  • 11. RFP  Mandatory  Requirements  Proposals  shall  define  …   6.5.1    …  a  Plaoorm  Independent  Security  Model  for  DDS     independent  of  the  programming  language  used…   6.5.2    …  a  collecKon  of  Plaoorm  Independent  IntercepKon   Points  and    SPIs  …   6.5.3  …    built-­‐in  Plaoorm  Independent  Security  Plugins  that   implement  the  Plaoorm  Independent  Interfaces   6.5.4    …  plaoorm  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  applicaKons  to  interoperate  securely   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   11  
  • 12. 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  ParKcipant  to  run  in  a   plaoorm   6.5.1.2    …  support  mechanisms  to  configure  and  access  the  credenKals  of  the  underlying   DDS  ParKcipants  …   6.5.1.3  …    allow  specificaKon  of  authorizaKon  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  ParKKon,  [6]  Subscribing  on  a  DDS  ParKKon   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  encrypKon    [4]  use  of  different  keys  for  data  from  different  DataWriters   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   12  
  • 13. Mandatory  Requirements  6.5.2:     Set  of  IntercepKon  Points  and  SPIs  The  Plugin  SPIs  shall  …   6.5.2.1    …  allow  applicaKons  to  exchange  credenKals  with  a  DDS  ParKcipant    [1]  exchanging  credenKals  for  authenKcaKon    [2]  delegaKon  of  authority  for  authenKcaKon   6.5.2.2    …  allow  an  external  plugin  to  perform  all  the  authorizaKon  funcKons      [1]  full  support  of  the  authorizaKon  policies    [3]  support  delegaKon  of  authority    [4]  support  delegaKon  of  authority  separately  for  each  DDS  Topic   6.5.2.3  …    allow  an  external  plugin  to  perform  all  the  tagging  and  tag-­‐accessing  funcKons   6.5.2.4    …  allow  an  external  plugin  to  perform  all  the  encrypKon  and  decrypKon   funcKons   6.5.2.5  …    external  plugin  to  perform  all  the  digital  signing  and  verificaKon  funcKons   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   13  
  • 14. RFP  OpKonal  Requirements  Proposals  may  define  authorizaKon  policies  that  control    …   6.6.1  …  the  content  a  DDS  ParKcipant  is  allowed  to  publish  on  a  Topic.   6.6.2  …  the  content  a  DDS  ParKcipant  is  allowed  to  subscribe  on  a  Topic..   6.6.3  …  the  QoS  Policies  a  DDS  ParKcipants  can  use  when  publishing  a  Topic   6.6.4  …  the  QoS  Policies  a  DDS  ParKcipant  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  authenKcaKon  and   authorizaKon  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  UnidirecKonal  Transports.   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   14  
  • 15. Submission  Guiding  Principles  •  Performance  &  Scalability   –  Do  not  impact  parts  of  the  system  that  do  not  have  security  needs   –  Allow  opKng  out  of  specific  features  such  as  MAC,  EncrypKon.  Digital  Signature  with  sufficient   granularity   –  Limit  use  of  asymmetric  keys  to  discovery  &  session  establishment     –  Support  MulKcast  •  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  mulK-­‐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:  consumpKon  of  samples  out  of  order,  best  efforts,  Kme  filters,  history  cache,   etc.  •  Leverage  exis:ng  technologies   –  Support  plugging  in  exiKng  technologies  for  ciphers,  MAC,  PKI  •  Ease  of  use  &  Flexibility   –  DO  not  preclude  integraKng  with  their  exisKng  security  and  crypto  infrastructure.   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   15  
  • 16. Audience  and  Purpose  for  this  SpecificaKon   •  Audience:   –  DDS  vendors/implementers,  not  the  users  of  DDS   •  Purpose:   –  Define  a  Security  Model  for  DDS  systems   –  Define  concrete  IntercepKon  points  in  the  middleware   where  SPI  interfaces  must  be  called   –  Define  concrete  SPI  Interfaces  vendors  must  invoke  at  the   IntercepKon  Points  and  the  behavior  upon  various   returns   –  Define  specific  SPI  implementaKons  to  the  extent   required  for  interoperability   –  NOT  guidance  to  users  implemenKng  secure  DDS  systems   –  NOT  definiKon  of  security  technologies  beyond  what  is   required  to  implement  the  specificaKon   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   16  
  • 17. MR#  6.5.1   Security  Model   •  A  security  model  is  defined  in  terms  of:   –  The  subjects  (principals)   –  The  objects  being  protected   •  The  operaKons  that  are  protected  on  the  objects   –  Access  Control  Model   •  A  way  to  map  each  subject  to  the  objects  they  can   perform  operaKons  on  and  which  are  the  allowed   operaKons  2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   17  
  • 18. Security  Model  Example:   UNIX  FileSystem  (simplified)  •  Subjects:    Users,  specifically  processes  execuKng  on  behalf  of  a  specific  userid  •  Protected  Objects:    Files  and  Directories  •  Protected  OperaKons  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  combinaKon  of  READ,  WRITE,  EXECUTE  permissions   for  the  assigned  OWNER  and  GROUP   –  Each  protected  operaKon  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   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   18  
  • 19. MR#  6.5.1   DDS  Security  Model  •  Subjects:    DDS  DomainParKcipant  (ParKcipant  GUID)  •  Protected  Objects:    DDS  Domain  and  DDS  Topic  •  Protected  Opera:ons  on  Objects  (logical  view):   –  DomainParKcipant.join   –  DomainParKcipant.add_read_parKKon   –  DomainParKcipant.add_write_parKKon   –  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   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   19  
  • 20. MR#  6.5.1  Mapping  of  DDS  API  to  protected  operaKons  DDS  API  Call     Protected  Opera:on  DomainParKcipantFactory.create_parKcipant  Discovery.match_remote_parKcipant   DomainParKcipant.join  DomainParKcipant.create_publisher  Publisher.set_qos   DomainParKcipant.add_write_parKKon  DomainParKcipant.create_subscriber  Subscriber.set_qos   DomainParKcipant.add_read_parKKon  DomainParKcipant.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   Topic.create_instance  Protocol.receive_instance_new  DataWriter.dispose   2/14/13  Protocol.receive_dispose   Topic.dispose_instance   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   20  
  • 21. Plaoorm  Independent  IntercepKon  Pts  +    SPIs     MR#  6.5.2  Service Plugin Purpose InteractionsAuthentication Authenticate the principal that is The principal may be an joining a DDS Domain. application/process or the user associated with that application Handshake and establish or process. shared secret between Participants may messages to participants do mutual authentication and establish shared secretAccess Control Decide whether a principal is allowed Protected operations include to perform a protected operation. joining a specific DDS domain, creating a Topic, reading a Topic, writing a Topic, etc.Cryptography Perform the encryption and Invoked by DDS middleware to decryption operations. Create & encrypt data compute and verify Exchange Keys. Compute digests, MAC, compute & verify Digital compute and verify Message Signatures Authentication Codes. Sign and verify signatures of messages.Logging Log all security relevant events Invoked by middleware to logData Tagging 2/14/13   Add a data ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   tag for each data sample 21  
  • 22. Plaoorm  Independent  SPIs    MR#  6.5.2  2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   22  
  • 23. MR#  6.5.3   BuilKn  Plugins  SPI   Buil:n  Plungin   Notes  AuthenKcaKon   PKI_AuthenKcaKonPlugin   Uses  PKI  with  a  pre-­‐configured   shared  CerKficate  Authority  AccessControl   PKI_PermissionsPlugin   Permissions  document  signed  by   shared  CerKficate  Authority  Cryptography   Crypto-­‐AES-­‐CTR-­‐HMAC-­‐DSA-­‐DH     AES128  and  AES256    for  encrypKon   (in  counter  mode)   SHA1  and  SHA256  for  digest   HMAC-­‐SHA1  and  HMAC-­‐256  for   MAC   DSA  and  Diffie-­‐Hellman  for   authenKcaKon  and  key  exchange  KeyManagement   PKI_Protected_DDS_KeyDistribuKon   Use  authorized  reader  PK  to   protect  KeyDistribuKon   Not  described  in  submission  DataTagging   Discovered_EndpointTags   Send  Tags  via  Endpoint  Discovery  Logging   DedicatedDDS_LogTopic   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   23  
  • 24. MR#  6.5.3   Crypto-­‐AES-­‐CTR-­‐HMAC-­‐DSA-­‐DH   •  EncrypKon  uses  AES  in  counter  mode   –  Similar  to  SRTP,  but  enhanced  to  support  mulKple   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  criKcal  to  support  DDS  QoS  like  history,  content   filters,  best-­‐efforts  etc.   •  DSA  and  Diffie-­‐Hellman  used  for  mutual   authenKcaKon  and  secure  key  exchanage  2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   24  
  • 25. MR#  6.5.4   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  2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   25  
  • 26. Use  of  DDS  Interoperability  Protocol   MR#  6.5.5   •  Uses:  Buil%nPar%cipantMessageWriter/Reader     –  Msg  kind:          KIND_SECURITY_AUTH_HANDSHAKE     •  data:          MessageToken   –  Msg  kind:          KIND_SECURITY_KEY_TOKEN   •  Data:        KeyToken   •  Discovery  propagates  addiKonal  security  info   –  Buil:nPar:cipantTopicData   •  Iden:tyToken                    [PID_SEC_IDENTITY_TOKEN]   •  PermissionsToken    [PID_SEC_PERMISSIONS_TOKEN]   –  Buil:nPublica:onTopicData   •  DataTags                                    [PID_SEC_DATA_TAGS]   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   26  
  • 27. Agenda   •  Status  recap   •  Summary  of  submission   •  What  has  changed?   •  Some  details   •  Status  &  Conclusion  2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   27  
  • 28. What  has  changed   •  Unified  Token  representaKons   –  All  Tokens  use  common  data-­‐type   –  Tokens  can  be  encrypted  (wrapped)  by  key   •  AuthenKcaKon  SPI  can  now  do:   –  Configurable  mulK-­‐step  Handshake    (subsumes  Challenge)   –  Establishment  of  Shared  Secret   •  Cryptography  SPI   –  Focuses  just  on  Crypto,  MAC,  DigitalSignature  and   KeyExchange   –  No  handshakes  anymore   •  Secure  envelopes   –  Data  protected  by  encrypKon  using  AES-­‐CTR  (as  before)   –  MAC  can  be  used  for  whole  RTPS  message  (as  before)   –  MAC  can  be  used  for  part  of  RTPS  message  (new)  2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   28  
  • 29. Agenda   •  Status  recap   •  Summary  of  submission   •  What  has  changed?   •  Some  details   •  Status  &  Conclusion  2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   29  
  • 30. Tokens  are  a  generic  mechanism  to  pass  informaKon  between  DDS  and  SPIs  Token  interpretaKon  defined  by  SPI  ImplementaKons  Some  tokens  are  propagated  via  DDS   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   30  
  • 31. Token  RepresentaKon   typedef string<> TokenClass; typedef string<> TokenWrappingClass; struct DDS_Property { char *property_name; char *property_value; }; struct DDS_Token { TokenClass token_classid; WrappingClass wrapping_classid; DDS_PropertySeq properties; DDS_OctetSeq value; DDS_OctetSeq wrapped_value; }; 2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   31  
  • 32. AuthenKcaKon  SPI   MR#  6.5.2   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   32  
  • 33. MR#  6.5.2   Meta-­‐Protocol  to   handshake  and   AuthenKcaKon   establish  shared  2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   Behavior   secret   33  
  • 34. BuilKn    DDS:Auth:PKI-­‐DSA-­‐DH    •  Uses  shared  CerKficate  Authority  (CA)   –  All  ParKcipants  pre-­‐configured  with  shared-­‐CA  •  Performs  mutual  authenKcaKon  between   discovered  parKcipants  using  the  Digital   Signature  Algorithm  (DSA)    •  Establishes  a  shared    secret  using  Diffie-­‐ Hellman.   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   34  
  • 35. ConfiguraKon  of  Auth:PKI-­‐DS-­‐DH   •  Three  things:   –  X.509  cerKficate  that  defines  the  shared  CA.  This   cerKficate  contains  the  Public  Key  of  the  CA.   –  RSA  private  key  of  the  DomainParKcipant.     –  An  X.509  cerKficate  that  chains  up  to  the  CA,  that   binds  the  DomainParKcipant  public  key    to  the   disKnguished  name  (subject  name)  for  the   parKcipant  and  any  intermediate  CA  cerKficates   required  to  build  the  chain   •  ConfiguraKon  API  outside  scope  of  specificaKon   –  Vendors  can  use  file,  QoS  property,  etc.  2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   35  
  • 36. Behavior  of  Auth:PKI-­‐DS-­‐DH   •  validate_local_parKcipant   –  IdenKtyCredenKalToken  has  X.509  cerKficate     –  Validates  cerKficate  against  CA   •  validate_remote_parKcipant   –  Receives  X.509  cert  of  remote  parKcipant  in   IdenKtyToken   –  Validates  X.509  cert  against  CA   –  Does  3-­‐message  handshake  to:   •  verify  possession  of  private  key     •  establish  SharedSecret  2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   36  
  • 37. ParKcipants  receive  X.509  Cert  of  remote  parKcipant  via  discovery   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   37  
  • 38. Each  ParKcipant  calls  validate_remote_idenKty()  this  checks  remote  X.509  Cert  against  locally-­‐configured    CA  ParKcipant  with  highest  GUID  returns  PENDING_HANDSHAKE_REQUEST,  the  other  PENDING_HANDSAHKE_MESSAGE   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   38  
  • 39. ParKcipant1  creates  CHALLENGE1  =  “CHALLENGE:<nonce>  and  sends  message  via  ParKcipantMessageWriter  with  MessageToken  :=  {CHALLENGE1}   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   39  
  • 40. ParKcipant2  creates  CHALLENGE2  :=  CHALLENGE:<nonce>  ParKcipant2    sends  to  ParKcipant1  message  with    MessageToken  :=  {SIGN(CHALLENGE1),  CHALLENGE2}   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   40  
  • 41. Part1  verifies  SIGN(CHALLENGE1)  using  Part2’s  PK  Part1    computes  a  SharedSecret  Part1  sends  message  with  contents:  MessageToken  :=  {SIGN(CHALLENGE2),  ENCRYPT(SharedSecret)}  Encrypt  uses  Part2’s  PK.   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   41  
  • 42. Part2  verifies  SIGN(CHALLENGE2)  using  Part1’s  PK  Part2    decrypts  SharedSecret  using  its  own  PK  We  have  Mutual  Authen:ca:on  and  a  SharedSecret   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   42  
  • 43. MR#  6.5.2   Access  Control  SPI  2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   43  
  • 44. 2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   44  
  • 45. BuilKn    DDS:AC:PKI    SPI  •  Configured  with:   –  X.509  CerKficate  of  shared  Permissions  CA   –  PermissionsCredenKalToken  •  PermissionsCredenKalToken  contains   –  XML  file  with  permissions   –  Includes  SubjectName  matching  the  one  on   IdenKtyCredenKalToken   –  All  signed  by  Permissions  CA   This  binds  the  permissions  to  the  indenKty  established  by   the  AuthenKcaKonPlugin   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   45  
  • 46. Example  Permissions  2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   46  
  • 47. BuilKn    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   BuilKnPublicaKonWriter:   –  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  •  EncrypKon  uses  AES  in  Counter  (CTR)  mode   –  The  session  counter  is  sent  on  EncryptedMessage  Envelope.   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   47  
  • 48. Conclusion  •  Submission  revised  based  on  addiKonal  implementaKon   experience  •  Plugin  APIs  modified  to  enhance  performance  and  support   implementaKons  that  want  to  use  MIKEY  exchanges  and   SRTP  style  encrypKon  •  A  few  things  are  sKll  missing   –  IDL  for  interfaces   –  Wire  protocol  parameter-­‐ID  assignment   –  Resolve  inconsistencies  in  document  •  TargeKng  March  2012  for  vote  to  recommend  adopKon  •  Joined  submissions   2/14/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   48