OMG DDS Security Standard

3,100 views

Published on

Revised Submission to the OMG Security RFP. Covers the plugin architecture and the proposed builtin plugins to provide Authentication, Access Control, Key Management, Confidentiality (Encryption), Message Authentication, and Auditing

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

No Downloads
Views
Total views
3,100
On SlideShare
0
From Embeds
0
Number of Embeds
22
Actions
Shares
0
Downloads
63
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

OMG DDS Security Standard

  1. 1. Your  systems.  Working  as  one.  DDS  SECURITY  Revised  Submission  Doc  num:  mars/2012-­‐06-­‐15   SubmiMer:  Gerardo  Pardo-­‐Castellote,  Ph.D.   Real-­‐Time  InnovaLons,  Inc.  CTO,  Real-­‐Time  InnovaLons,  Inc.   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved  
  2. 2. Agenda   •  Background   •  Requirements   •  Threats   •  Security  Model   •  Plugins  and  SPIs   •  BuilLn  Plugins   •  Status  &  Conclusion  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   2  
  3. 3. Security  Terms:  a  Safe-­‐Deposit  Box   •  AuthenLcaLon:  The  bank  knows  who  you  are;  you   must  show  ID.   •  Access  Control:  The  bank  only  lets  those  on  an   access  list  into  your  box.   •  ConfidenLality:  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  repudiaLon:  You  sign  when  you  come  in  and   out  so  you  can’t  claim  that  you  weren’t  there.   •  Availability:  The  bank  is  always  open.     6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved  33
  4. 4. Security  as  a  system  problem   •  UlLmately  security  is  a  system  property   –  Involves  hardware,  soware,  humans,   procedures…   •  Most  directly  related:  Scope  of   1.  Securing  the  data-­‐cenLrc  bus  the  RFP   2.  IntegraLng  across  security  domains  Out   3.  Securing  the  operaLng  system  of  Scope   4.  Securing  the  hardware  &  soware   configuraLon   6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   4  
  5. 5. Three  security  boundaries   Ul5mately  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  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   5  
  6. 6. Fine-­‐Grained  Data-­‐Centric  Security   Topics   •  Access  control  per  Topic   •  Read  versus-­‐write  permissions   •  Field-­‐specific  permissions  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   6  
  7. 7. Data  Security  Example:  UAV   Topics   Authen5ca5on   Access   Integrity   Non-­‐ Confiden5ality   Control   repudia5on   UAV  health   X   X   data   Remote   X   X   X   X   X   commands   Sensor  Data   X   X   X   X  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   7  
  8. 8. Agenda   •  Background   • Requirements   •  Threats   •  Security  Model   •  Plugins  and  SPIs   •  BuilLn  Plugins   •  Status  &  Conclusion  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   8  
  9. 9. RFP  Mandatory  Requirements  Proposals  shall  define  …   6.5.1    …  a  Plahorm  Independent  Security  Model  for  DDS     independent  of  the  programming  language  used…   6.5.2    …  a  collecLon  of  Plahorm  Independent  IntercepLon   Points  and    SPIs  …   6.5.3  …    built-­‐in  Plahorm  Independent  Security  Plugins  that   implement  the  Plahorm  Independent  Interfaces   6.5.4    …  plahorm  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  applicaLons  to  interoperate  securely   6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   9  
  10. 10. 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  ParLcipant  to  run  in  a   plahorm   6.5.1.2    …  support  mechanisms  to  configure  and  access  the  credenLals  of  the  underlying   DDS  ParLcipants  …   6.5.1.3  …    allow  specificaLon  of  authorizaLon  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  ParLLon,  [6]  Subscribing  on  a  DDS  ParLLon   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  encrypLon    [4]  use  of  different  keys  for  data  from  different  DataWriters   6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   10  
  11. 11. Mandatory  Requirements  6.5.2:     Set  of  IntercepLon  Points  and  SPIs  The  Plugin  SPIs  shall  …   6.5.2.1    …  allow  applicaLons  to  exchange  credenLals  with  a  DDS  ParLcipant    [1]  exchanging  credenLals  for  authenLcaLon    [2]  delegaLon  of  authority  for  authenLcaLon   6.5.2.2    …  allow  an  external  plugin  to  perform  all  the  authorizaLon  funcLons      [1]  full  support  of  the  authorizaLon  policies    [3]  support  delegaLon  of  authority    [4]  support  delegaLon  of  authority  separately  for  each  DDS  Topic   6.5.2.3  …    allow  an  external  plugin  to  perform  all  the  tagging  and  tag-­‐accessing  funcLons   6.5.2.4    …  allow  an  external  plugin  to  perform  all  the  encrypLon  and  decrypLon   funcLons   6.5.2.5  …    external  plugin  to  perform  all  the  digital  signing  and  verificaLon  funcLons   6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   11  
  12. 12. RFP  OpLonal  Requirements  Proposals  may  define  authorizaLon  policies  that  control    …   6.6.1  …  the  content  a  DDS  ParLcipant  is  allowed  to  publish  on  a  Topic.   6.6.2  …  the  content  a  DDS  ParLcipant  is  allowed  to  subscribe  on  a  Topic..   6.6.3  …  the  QoS  Policies  a  DDS  ParLcipants  can  use  when  publishing  a  Topic   6.6.4  …  the  QoS  Policies  a  DDS  ParLcipant  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  authenLcaLon  and   authorizaLon  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  UnidirecLonal  Transports.   6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   12  
  13. 13. Agenda   •  Background   •  Requirements   • Threats   •  Security  Model   •  BuilLn  Plugins   •  Plugins  and  SPIs   •  Status  &  Conclusion  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   13  
  14. 14. Threats  Alice:  Allowed  to  publish  topic  T   1.  Unauthorized  subscripLon  Bob:  Allowed  to  subscribe  to  topic  T  Eve:  Non-­‐authorized  eavesdropper     2.  Unauthorized  publicaLon  Trudy:  Intruder   3.  Tampering  and  replay    Trent:  Trusted  infrastructure  service  Mallory:  Malicious  insider   4.  Unauthorized  access  to  data   by  infrastructure  services     6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   14  
  15. 15. Data-­‐centric/mulLcast  Insider  Threats     •  Two  insider  threats  affecLng  (mulLcast)  data-­‐ centric  systems  are  of  unique  significance   1.  Reader  mis-­‐behaves  as  unauthorized  writer   An  applicaLon  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    6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   15  
  16. 16. Reader  mis-­‐behaves  as  unauthorized   writer  •  SituaLon:   –  Alice  -­‐    creates  a  Crypto  Key  per  Topic/DataWriter   –  Alice  -­‐  shares  its  Key  with  all  intended  readers  as  needed  to  mulLcast   –  Mallory  –  is  an  authorized  reader  so  it  has  Alice’s  key   –  Mallory  –  behaves  maliciously  and  uses  Alice’s  key  to  create  fake  UDP  messages  purng   Alice’s  informaLon  (IP,  Port,  GUIDs,  etc.)  but  with  bad  data.  •  ImplicaLons:   –  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  aMack  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   6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   16  
  17. 17. Compromise  of  Infrastructure  Service  (2)     UDP   RTPS   SubMsg   DATA   SubMsg   DATA   Hdr   Hdr   Hdr(T1)   (T1)   Hdr(T2)   (T2)  •  SituaLon:   –  Alice  creates  a  Crypto  Key  to  write  topic  T   MAC  +  EncrypLon   –  Alice  encrypts  the  whole  RTPS  sub-­‐message  related  to  topic  T   –  Trent  is  an  infrastructure  (e.g.  relay)  that  must  store  and  forward  data  from  Alice  to  Bob   •  To  operate  Trent  needs  to  see  submessage  header  informaLon:  GUIDs,  SequenceNumber,  KeyHash,  …   –  Alice  shares  the  key  used  for  topic  T  with  Trent   •  Trent  has  access  to  the  keys  for  all  the  data  it  relays   –  Trent  is  aMacked  and  compromised  •  ImplicaLons:   –  Trent  aMacker  has  access  to  all  the  keys  for  all  the  topics  that  Trent  was  relaying     –  Infrastructure  must  be  granted  “super  user  privileges”  to  see  many  topics  despite  fact  they  have   no  need  to  see  the  data   –  Compromise  of  a  single  infrastructure  service  can  be  lead  to  catastrophic  informaLon  leakage  •  Notes:   –  The  problem  is  that  Trent  is  given  access  to  secrets  that  allow  it  to  see  the  data  despite  the  fact   that  it  does  not  have  a  need  to  do  so,  effecLvely  elevaLng  its  privileges  and  creaLng  a  big   vulnerability   –  The  problem  can  be  solved  if  the  submessage-­‐header  informaLon  Trent  needs  is  not  encrypted   with  the  same  key  as  the  topic  eal-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   6/25/12   ©  2012  R data.   17  
  18. 18. The  submission  must  address  these  vulnerabiliLes   •  Maintain  separaLon  between  different  classes  of  data  receivers   1.  Cannot  access  any  informaLon  on  topic  T   2.  Can  relay  the  submessages  on  topic  T,  but  not  the  payload  data   3.  Can  access  the  payload  data  on  topic  T  but  not  relay  messages   •  Examples:   –  UnauthenLcated  or  Non-­‐authorized  applicaLons.  ApplicaLons  without  the  rights   to  join  a  specific  DDS  domain   –  DDS  Persistence  Service  which  is  allowed  to  store  encrypted  payload.  Recording   Services,  Gateways  and  rouLng  components   •  They  need  to  see  enough  (Topic,  Key,  Sequence  Numbers)  but  not  the  data     –  AuthenLcated  applicaLons  authorized  to  read  data  on  a  specific  Topic   •  This  can  be  enforced  by  combining  a  MAC  and  EncrypLon  and  sharing   these  keys  selecLvely   –  MAC  Key  shared  with  relay  service   –  MAC  &  Crypto  Key  shared  with     UDP   Hdr   RTPS   Hdr   SubMsg   Hdr(T1)   DATA   (T1)   SubMsg   Hdr(T2)   DATA   (T2)              authorized  readers     This  is  not  in  the  submission  yet   MAC   EncrypLon       6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   18  
  19. 19. Agenda   •  Background   •  Requirements   •  Threats   • Security  Model   •  Plugins  and  SPIs   •  BuilLn  Plugins   •  Status  &  Conclusion  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  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  opLng  out  of  specific  features  such  as  MAC,  EncrypLon.  Digital  Signature  with  sufficient   granularity   –  Limit  use  of  asymmetric  keys  to  discovery  &  session  establishment     –  Support  MulLcast  •  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  mulL-­‐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:  consumpLon  of  samples  out  of  order,  best  efforts,  Lme  filters,  history  cache,   etc.  •  Leverage  exisLng  technologies   –  Support  plugging  in  exiLng  technologies  for  ciphers,  MAC,  PKI  •  Ease  of  use  &  Flexibility   –  DO  not  preclude  integraLng  with  their  exisLng  security  and  crypto  infrastructure.   6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   20  
  21. 21. Audience  and  Purpose  for  this  SpecificaLon  •  Audience:   –  DDS  vendors/implementers,  not  the  users  of  DDS  •  Purpose:   –  Define  a  Security  Model  for  DDS  systems   –  Define  concrete  IntercepLon  points  in  the  middleware   where  SPI  interfaces  must  be  called   –  Define  concrete  SPI  Interfaces  vendors  must  invoke  at  the   IntercepLon  Points  and  the  behavior  upon  various   returns   –  Define  specific  SPI  implementaLons  to  the  extent   required  for  interoperability   –  NOT  guidance  to  users  implemenLng  secure  DDS  systems   –  NOT  definiLon  of  security  technologies  beyond  what  is   required  to  implement  the  specificaLon   6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   21  
  22. 22. Security  Model   •  A  security  model  is  defined  in  terms  of:   –  The  subjects  (principals)   –  The  objects  being  protected   •  The  operaLons  that  are  protected  on  the  objects   –  Access  Control  Model   •  A  way  to  map  each  subject  to  the  objects  they  can   perform  operaLons  on  and  which  are  the  allowed   operaLons  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   22  
  23. 23. Security  Model  Example:   UNIX  FileSystem  (simplified)  •  Subjects:    Users,  specifically  processes  execuLng  on  behalf  of  a  specific  userid  •  Protected  Objects:    Files  and  Directories  •  Protected  OperaLons  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  combinaLon  of  READ,  WRITE,  EXECUTE  permissions   for  the  assigned  OWNER  and  GROUP   –  Each  protected  operaLon  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   6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   23  
  24. 24. DDS  Security  Model  •  Subjects:    DDS  DomainParLcipant  (ParLcipant  GUID)  •  Protected  Objects:    DDS  Domain  and  DDS  Topic  •  Protected  Opera5ons  on  Objects  (logical  view):   –  DomainParLcipant.join   –  DomainParLcipant.add_read_parLLon   –  DomainParLcipant.add_write_parLLon   –  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   6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   24  
  25. 25. Mapping  of  DDS  API  to  protected  operaLons  DDS  API  Call     Protected  Opera5on  DomainParLcipantFactory.create_parLcipant  Discovery.match_remote_parLcipant   DomainParLcipant.join  DomainParLcipant.create_publisher  Publisher.set_qos   DomainParLcipant.add_write_parLLo n  DomainParLcipant.create_subscriber  Subscriber.set_qos   DomainParLcipant.add_read_parLLo n  DomainParLcipant.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   6/25/12  Protocol.receive_instance_new   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   25  
  26. 26. Access  Control  Model  •  Flexible  Access  Control  Model  implemented  by  the  AccessControl   SPI.     –  AccessControl  plugin  implementaLons  can  customize  the  behavior.  •  General  Access  Control  Model     –  Each  subject  (DomainParLcipant)  is  configured  with  a  set  of  permissions   –  The  AccessControl  Plugin  intercepts  each  of  the  protected  operaLons  and  decides   whether  is  is  allowed  or  denied.    •  Access  Control  Model  implemented  by  builLn-­‐plugins:   –  Explicit  permissions  assigned  to  DomainPaLcipants  based  on  the  Topic  name  (in   current  submission)   –  Role-­‐based  access  control   –  Label-­‐based  access  control   6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   26  
  27. 27. Example:  Explicit  permissions          <permisions  xsi:noNamespaceSchemaLocation="omg_shared_ca_permissions.xsd"                                    xmlns:xsi="http://www.w3.org/2001/XMLSchema-­‐instance">          <validity>                  <!-­‐-­‐  Format  is  YYYYMMDDHH  in  GMT-­‐-­‐>                  <not_before>2012060113</not_before>                  <not_after>2013060113</not_after>          </validity>          <subject_name>/C=US/ST=CA/L=Sunnyvale/O=ACME  Inc./OU=CTO  Office/CN=DDS   Shapes  Demo/emailAddress=cto@acme.com</subject_name>          <allow_with_exceptions>                  <domain_id>0</domain_id>                  <allow>                          <publish>Sq*</publish>                          <subscribe>Circle</subscribe>                  </allow>                  <exception>                          <publish>SquareControl</publish>                  </exception>          </allow_with_exceptions>   </permissions>  •  The  DomainParLcipant  is  allowed  to  join  domain  0  •  Within  domain  0  the  DomainParLcipant  is  allowed  to  wriLng  any  Topic  with  a  name  that   matches  the  expression  “Sq*”  with  the  excepLon  of  Topic  named  “SquareControl”  •  Within  domain  0  the  DomainParLcipant  is  allowed  to  read  only  the  Topic  named  “Circle”     6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   27  
  28. 28. Pluggable  Security  Architecture   cerLficates   applicaLon  component   App.   App.   App.   AuthenLcaLon   Secure  DDS     Key   Plugin   middleware   Management   ? Plugin   Other     Other   Other       Access  Control   DDS   Plugin   DDS  EnLLes   Cryptography   DDS   DDS   System   System   Plugin   System   AudiLng   Protocol   Data   Plugin   Engine   cache   Tagging   Plugin   Secure  Transport  (e.g.  TLS)   Kernel   ? Crypto   Policies   Module   Network   (e.g.  TPM  )     Driver      Secure  Kernel   TA Encrypted   G   Data  ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved  6/25/12   Network   28  
  29. 29. Service  Plugins  (SPIs)     •  Authen5ca5on:  Provides  the  mechanism  to  verify  that  idenLty  of   the  applicaLon  and  or  user  that  invokes  operaLons  on  DDS  in   order  to  join  a  domain,  publish,  subscribe,  etc.   •  AccessControl:  Provides  the  means  to  enforce  policy  decisions  on   what  DDS  related  operaLons  an  authenLcated  user  can  perform.   For  example  which  domains  it  can  join,  which  Topics  it  can  publish   or  subscribe,  etc.   •  Cryptography:  Implements  (or  interfaces  with  libraries  that   implement)  all  cryptographic  operaLons,  including  encrypLon,   decrypLon,  digital  signatures,  etc.   •  KeyManagement:  Provides  key  distribuLon  and  access  services.  It   allows  DDS  implementaLons  to  access  the  necessary  keys  given   the  idenLty  and  access  control  policies.   •  Tagging:  Tag/Label  data  samples.   •  Logging:  Supports  audiLng  of  all  DDS  security-­‐relevant  events.  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   29  
  30. 30. 6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   30  
  31. 31. IntercepLon  Points:  Current  logical  flow   Create   Domain   AuthenLcate   ParLcipant     DP?   Create   Endpoints   Discover   remote  DP   Discover   remote   Endpoints   Send/ Receive  data  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   31  
  32. 32. IntercepLon  Points  inserted  into  the  logical  flow   Create   Domain   Domain   AuthenLcate   No   ParLcipant   AuthenLcate   DP?   ParLcipant     Create  Fails   Yes   DP?   Create   No   Endpoint   Access  OK?   Endpoints   Create  Fails   Discover   AuthenLcate   No   Ignore   remote  DP   Remote  DP?   Remote  DP   Yes   Discover   Ignore   remote   Access  OK?   remote   Endpoints   endpoint   Send/ Message   Receive  data   security   6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   32  
  33. 33. AuthenLcaLon  -­‐  Local   Create   Load   Domain   Domain   IdenLty   AuthenLcate   No   ParLcipant   AuthenLcate   DP?   ParLcipant     CerLficates   Create  Fails   DP?   Yes   For  PKI,   token  is  PKI   Get  Auth   cerLficate   Token  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   33  
  34. 34. DDS  Security  Flow:  Access  Control   Load   No   Create   Endpoint   Security   Access  OK?   Endpoints   Create  Fails   Policies   Yes   Data  Writer?   Yes   Get  Keys   If  desired,   add  tag  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   34  
  35. 35. IntercepLon  Points  –  Remote  AuthenLcaLon   and  Access  Control   Discover   Receive   AuthenLcate   No   Ignore   remote  DP   IdenLty  Token   Remote  DP?   Remote  DP   Yes   Discover   No   Ignore   Receive   remote   Access  OK?   remote   Permissions  Token   Endpoints   endpoint   Yes   Does  the   Matched  DW?   remote  Data   Writer   Yes   match  a   Get  Keys   local  Data   Reader   Get  remote   DW  tag  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   35  
  36. 36. DDS  Security  Flow:  Send  Data   Access   Yes   Write   Marshall   Encrypt?   CriptoKeys  +   No   Encrypt   ClearText   CipherText   CipherText   Header  has   KeyId     Marshal   Access   SampleInfo   DigitalSig?   PrivateKey  +   (KeyHash,   Yes   Sign   SN,  GUID)   TBD:  DSig   Append  Digital  Signature   Header   Yes   precedes   Access   ciphertext?  Send  RTPS   Assemble   MACKeys  +  Message  to   MAC?   Submessages   Yes   compute  MAC  DesLnaLon   TBD:     Append  MAC   MAC  as  separate   submessage?     Send  to  UDP   First  or  last?     6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   In  RTPS  Header?   36  
  37. 37. Agenda   •  Background   •  Requirements   •  Threats   •  Security  Model   • Plugins  and  SPIs   •  BuilLn  Plugins   •  Status  &  Conclusion  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   37  
  38. 38. 6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   38  
  39. 39. AuthenLcaLon  Plug-­‐in   •  Goal:  authorize  DDS  enLLes.    Only  an  authorized   DDS  applicaLon  can  send  or  receive  data  in  that   domain   •  The  unique  idenLty  of  a  Domain  ParLcipants  is   locally  authenLcated   •  When  a  remote  Domain  ParLcipant  is  discovered,  its   idenLty  must  be  validated   AuthenLcaLon   Service   DDS   DDS   DDS   App   App  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   39  
  40. 40. AuthenLcaLon  SPI   •  IdenLtyCredenLal:  configures  the   plugin  with  the  informaLon  it   needs  to  idenLfy  and  authenLcate   the  local  parLcipant   •  IdenLtyHandle:  used  refer  locally   to  an  authenLcated  parLcipant.   •  IdenLtyToken:  characterizes  the   idenLty  informaLon  of  a   DomainParLcipant,  which  is   propagated  via  discovery   •  AuthenLcaLonListener  noLfy  of   status  changes:  E.g.  when  a   cerLficate  has  expired  and  revokes   the  idenLty    6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   40  
  41. 41. AuthenLcaLon  OperaLons  Opera5on   Descrip5on  validate_local Validates the identity of the local DomainParticipant based on_identity credentials, biometrics or whatever the plug-in requires.validate_remot Validates the identity of the remote DomainParticipant, based one_identity an IdentityToken representation. This operation may return an Identity Challenge that must be sent and replied to by the remote participant.get_identity_t Returns an IdentityToken that can be sent over the network tooken identify the DomainParticipant.challenge_iden Asks the local AuthenticationPlugin to respond to an identitytity challenge. The operation is invoked if a remote Participant sends a message requesting an identity challengevalidate_ident Provides the AuthenticationPlugin with the response to anity_challenge identity challenge that was previously requested as a result of a call to validate_remote_identityset_listener Sets the listener necessary for determining identity status changes to the AuthenticationListener objects received as an argument. 6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   41  
  42. 42. Access  Control  SPI  Access  Control  SPI   •  PermissionsCredenLal:   provided/configured  on  the   DomainParLcipant  to     prove  its  permissions   •  PermissionsHandle:   internal  handle  to  refer  to   the  permissions  of  an   idenLfied   DomainParLcipant   •  PermissionsToken:   characterizes  the   DomainParLcipant   permissions,  which  is   propagated  via  discovery   •  AccessControlListener   noLfy  of  status  changes.   E.g.  a  change  in   permissions.   6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   42  
  43. 43. Access  Control  OperaLons  Opera5on   Descrip5on  validate_loc Validates the permissions of the local DomainParticipant. Theal_permissio permissions could be based on a PermissionsCredentialns()   presented to the plugin. The operation returns a PermissionsHandle object, if successful.validate_rem Validates the permissions of the remote DomainParticipant,ote_permissi propagated as a PermissionsToken. The operation returns aons()   PermissionsHandle, if successful.check_create Enforces the permissions of the local DomainParticipant._particpant Ensurng it is allowed to join the specified domain_id with the()   specified Participant QoS.check_create Enforces permissions to ensure the local DomainParticipant is_datawriter allowed to write the specified Topic with the specified QoS.()check_create Enforces permissions to ensure the local DomainParticipant is_datareader allowed to read the specified Topic with the specified QoS.()check_create Enforces permissions to ensure the local DomainParticipant is_topic()   6/25/12   allowed©  2012  Real-­‐Time  Ithe specified Topic with the specified QoS. to create nnovaLons,  Inc.    -­‐    All  rights  reserved   43  
  44. 44. Access  Control  OperaLons  (II)  Opera5on   Descrip5on  check_local_da In case the access control requires a finer granularity at the instancetawriter_regis level, this operation enforces the permissions of the local DataWriterter_instance()   to create a particular instance.check_local_da In case the access control requires a finer granularity at the instancetawriter_dispo level, this operation enforces the permissions of the local DataWriterse_instance()   to delete a particular instance.check_remote_p Enforces the permissions on the remote DomainParticipant,articipant()   ensuring it has permissions to join the domain with the specified domain_id and QoS.check_remote_d Enforces the permissions on the remote DomainParticipantatawriter()   ensuring is has permissions to write data on the specified Topic name and type (extracted from the publication_data) and with the discovered QoS.check_remote_d Enforces the permissions on the remote DomainParticipantatareader()   ensuring is has permissions to read data on the specified Topic name and type (extracted from the publication_data) and with the discovered QoS.check_remote_t Enforces permissions to ensure the remote DomainParticipant isopic()   allowed to create the specified Topic with the specified QoS. 6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   44  
  45. 45. Access  Control  OperaLons  (III)  Opera5on   Descrip5on  check_remote In case the access control requires a finer granularity at the instance_datawriter_ level, this operation checks the permissions of the remoteregister_ins DataWriter allow it to create a particular instance.tance()  check_remote In case the access control requires a finer granularity at the instance_datawriter_ level, this operation checks the permissions of the remotedispose_inst DataWriter allow it to delete a particular instance.ance()  get_permissi Returns the PermissionsToken that can be used to represent onons_token() the network the Participant’s permissions, which are identified by the specified PermissionsHandle.set_listener Sets the listener for the AccessControl object.() 6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   45  
  46. 46. Access  Control  Listener  OperaLons  Opera5on   Descrip5on  on_revoke_pe DomainParticipants’ Permissions can be revoked/changed.rmissions()   This listener provides a callback for permission revocation/changes. 6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   46  
  47. 47. Cryptographic  Plug-­‐in   Goal:  Provide  cryptographic  capabiliLes  for  DDS  data  samples   •  Customer  security  policy  dictates  which  per  sample  cryptography   is  required   –  MAC  for  message  authenLcaLon  and  integrity   –  Digest  for  integrity  or  as  part  of  compuLng  a  Digital  Signature   –  Digital  signature   –  EncrypLon   •  Highlights:   –  Designed  to  support  different  encrypLon  methods   •  PKI,  Symmetric  keys,  IdenLty  based  encrypLon   •  Counter-­‐mode  encrypLon  (for  non  stream-­‐oriented  sessions)   –  General  and  extensible  API     •  can  support  different  implementaLons  of  the  crypto,  including  interfacing   with  device  drives  and  hardware   –  Designed  for  performance   •  Separate  prepare  &  execute  cycles   •  Supports  performing  cryptographic  operaLons  on  non-­‐conLguous  buffers  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   47  
  48. 48. Cryptographic  SPI   Provides  support  for:   •  Encrypt/Decrypt   •  MessageAuthenLcaLon   •  Digital  signature  &   verificaLon   6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   48  
  49. 49. Main  Types   •  Handle  (CryptoHandle,  CryptoSession  MACHandle,   DSigHandle):   –  Provide  internal  handle  to  “prepared”  key  material  inside   the  Plugin  for  efficient  operaLons   •  Token  (CryptoToken,  MACToken,  DSigToken):   –  Encode  all  the  informaLon  needed  to  iniLalize  the   algorithms.  This  informaLon  created  at  the  request  of     applicaLon  generaLng  the  message  and  made  available  to   the  authorized    recipients  with  the  help  of  the   MeyManager  plugin   •  State  (CryptoState,  CryptoState  MACState,   DSigState):   –  Internal  handle  to  algorithmic  state  to  support  operaLons   on  non-­‐conLguous  buffers  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   49  
  50. 50. Cryptographic  OperaLons  Opera5on   Descrip5on  decrypt() Given a cryptographic token and encrypted data, this function generates decrypted output. This will be used by a DataReader to decrypt encrypted data it received on the wire.  encrypt() Given an encryption token and data, this function generates encrypted output. This will be used by a DataWriter to encrypt data prior to sending it out on the wire.  get_cypher_in Returns the corresponding to a CryptographicToken.  fo_from_token()get_key_from_ Returns the CryptographicKey corresponding to atoken() CryptographicToken.  get_local_enc Returns the local cryptographic token, CryptographicToken,ryption_token given the local key.()get_remote_en Returns the remote CryptographicTokengiven the cypher infocryption_toke for it. In order to achieve interoperability, the cipher info needs to ben() 6/25/12   known.   2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   ©   50  
  51. 51. Cryptographic  OperaLons  (II)  Opera5on   Descrip5on  set_key_for_t Associates a cryptographic key to a cryptographic token.  oken()sign() Digitally signs the data and attaches the signatures on the wire.  verify() Verifies the signature of the data.   6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   51  
  52. 52. Key  Management  Plug-­‐In   Goal:  enable  efficient  method  for  management  of   cryptographic  keys   •  Each  Data  Writer  needs  a  key  for   –  EncrypLon   –  Message  AuthenLcaLon  Codes   –  Digital  Signature  (oen  the  PKI  cert  private  key)   •  A  Matched  Data  Reader  needs  matching  key   •  The  KeyManagent  plugin  is  responsible  for   propagaLng  the  different  Keys  to  the  authorized   readers      6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   52  
  53. 53. Key  Management  SPI   •  KeyManagerTokenHandle:  local  opaque  reference   to  a  previously  stored  token   •  TokenAccessTicket:  Opaque  Lcket  granLng  access   to  a  key  to  an  idenLfied  DomainParLcipant   6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   53  
  54. 54. Highlights   •  Generic  API  supports  custom  and  well  as  commercial   Key  Managers   •  Integrates  well  with  exisLng  DDS  mechanisms   •  Model:   –  The  KeyManager  stores  keys  (KeyTokens)  at  the  request  of   the  sender   –  The  sender  requests  a  Ticket  to  be  generated  for  to   granLng  access  to  a  KeyToken  to  a  specific  subject  Iden5ty   (DomainParLcipant).     –  The  sender  can  share  the  Ticket  with  the  intended   recipient.  This  message  does  not  need  to  be  protected   –  Upon  presentaLon  of  the  Ticket    by  the  intended  Iden5ty   the  KeyManager    gives  it  the  KeyToken.  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   54  
  55. 55. Key  Management  OperaLons  Opera5on   Descrip5on  store_token() Stores a Token a cryptographic Token in the Manger retuning a KeyManagerTokenHandle that can be used to locally refer to the stored Token.get_token_acce Returns a Ticket for a previously stored Token to be used by ass_ticket()   specified subject Identitity. The Ticket grants access to the Token only to the identity that was specified so it maybe shared in cleartext with the intended recipient.  lookup_token_h Looks up a Token given a Ticket. The KeyManager willandle() ensure that the identity of the requester is the one for whom the Ticket was intended. Returns a KeyManagerTokenHandle that can be used to locally refer to the stored Token.get_token() Retrieves a previously stored Token given its local KeyManagerTokenHandle. 6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   55  
  56. 56. Key  Management  Listener  OperaLons  Opera5on   Descrip5on  identity_chall Used   to   enforce   that   only   the   intended   recipient   idenLty   can   get  enge() access  to  a  stored  Token 6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   56  
  57. 57. Logging  (AudiLng)  Plug-­‐in   •  Goal:  Provide  mechanism  to  log  either  locally   or  centralized  all  security  events  for  audiLng   DDS  App   Secure   Audit   Plug-­‐ DB   ins  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   57  
  58. 58. Data  Tagging   •  Tag  is  added  to  a  Data  Writer   •  Tag  is  propagated  over  discovery   •  The  Data  Reader  stores  the  tag  of  each  Data   Writer   •  When  the  Data  Reader  applicaLon  gets  a  data   sample,  it  can  retrieve  the  tag  associated  with   that  sample  from  the  middleware    6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   58  
  59. 59. Agenda   •  Background   •  Requirements   •  Threats   •  Security  Model   •  Plugins  and  SPIs   • Buil5n  Plugins   •  Status  &  Conclusion  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   59  
  60. 60. BuilLn  Plugins  SPI   Buil5n  Plungin   Notes  AuthenLcaLon   SharedCA_AuthenLcaLonPlugin   Uses  PKI  with  a  pre-­‐configured   shared  CerLficate  Authority  AccessControl   SharedCA_PermissionsPlugin   Permissions  document  signed  by   shared  CerLficate  Authority  Cryptography   Crypto-­‐AES-­‐CTR-­‐HMAC     AES128  and  AES256    for  encrypLon   (in  counter  mode)   SHA1  and  SHA256  for  digest   HMAC-­‐SHA1  and  HMAC-­‐256  for   MAC   PKI  digital  signature  KeyManagement   PKI_Protected_DDS_KeyDistribuLon   Use  authorized  reader  PK  to   protect  KeyDistribuLon   Not  described  in  submission  DataTagging   Discovered_EndpointTags   Send  Tags  via  Endpoint  Discovery  Logging   DedicatedDDS_LogTopic   6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   60  
  61. 61. SharedCA_AuthenLcaLonPlugin  (1)   •  2048-­‐bit  RSA  x.509  CerLficates  in  combinaLon  with  a   configurable  shared  CerLficate  Authority  (CA)   •  Each  ParLcipant  is  configured  with     –  Shared  CA  described  by  self-­‐signed  cerLficate  (e.g.  PEM,   DER  formats)     –  The  ParLcipant  Private  Key  (e.g.  PEM,  DER)   –  The  ParLcipant  signed  cerLficate  from  the  CA  binding  the     •  DisLnguished  Name  for  the  parLcipant   •  ParLcipant  Public  Key   –  AuthenLcaLonToken  is  signed  cerLficate  in  PEM  format   •  All  implementable  with  openssl  toolkit  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   61  
  62. 62. SharedCA_AuthenLcaLonPlugin  (2)   •  Local  idenLty  is  verified  by  presence  of  private   key  that  corresponds  with  PK  in  cerLficate   •  Remote  IdenLty  verified  via  challenge.   –  Plugin  create  a  NONCE  and  sends  as  a  challenge  to   remote  parLcipant   –  Remote  ParLcipant  Pluging  must  encrypt  NONCE   with  private  key   –  Plugin  checks  response  against  the  PublicKey  in  the   cerLficate   –  These  messages  flow  over  the  exisLng   ParLcipantMessage  builLn  Topic  6/25/12   ©  2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   62  
  63. 63. Example  self-­‐signed  cerLficate  for  CA   CerLficate:          Data:                  Version:  1  (0x0)                  Serial  Number:                          9a:49:85:d1:3e:b9:85:04                  Signature  Algorithm:  sha1WithRSAEncrypLon                  Issuer:  C=US,  ST=MA,  L=Boston,  O=OMG,  OU=DDS  SIG,  CN=DDS  Security  Specifica5on/emailAddress=dds@omg.org                  Validity                          Not  Before:  May  31  00:11:29  2012  GMT                          Not  Aer  :  May  31  00:11:29  2013  GMT                  Subject:  C=US,  ST=MA,  L=Boston,  O=OMG,  OU=DDS  SIG,  CN=DDS  Security  Specifica5on/emailAddress=dds@omg.org                  Subject  Public  Key  Info:                          Public  Key  Algorithm:  rsaEncrypLon                          RSA  Public  Key:  (2048  bit)                                  Modulus  (2048  bit):                                          00:c5:8e:2b:3d:d1:97:a6:ce:8b:1f:91:0b:5b:1c:                                          5a:a0:60:42:b4:b8:89:35:40:de:9c:a0:51:12:25:                                          63:51:67:4c:26:8a:48:00:d0:98:0a:a0:2b:9b:ea:                                          50:9f:12:1e:9c:27:92:76:c4:38:4d:94:a1:38:37:                                          86:46:45:~:8e:b1:a4:b5:76:35:1a:6c:17:5c:05:                                          25:66:b7:f4:58:e4:6c:ad:a3:17:ef:fe:3b:ec:fa:                                          7b:60:e0:7f:9e:f3:a3:0b:a0:91:5f:ef:32:c7:d7:                                          57:37:8c:49:58:9c:be:fd:2b:b8:4c:3a:44:a0:c3:                                          6b:63:a0:ae:97:1d:bf:b0:af:09:3f:fc:ca:4d:1a:                                          8e:c4:1c:fd:db:2c:a8:20:e7:2d:61:8d:38:c3:46:                                          d5:94:0c:78:aa:17:e4:32:08:49:ed:8a:fa:b0:ce:                                          fc:bd:e4:8f:5a:53:73:b4:1c:a7:68:b4:39:b3:b3:                                          ff:~:80:ff:f3:87:ba:cc:48:5a:ed:b7:04:81:d4:                                          b5:89:48:ba:b5:3c:c3:9a:cd:6f:5a:94:ea:06:e5:                                          fa:b6:ee:ce:04:29:2a:ea:1d:54:2f:83:ef:c9:~:                                          5e:9e:ca:a7:74:c9:53:30:b7:fe:7d:e5:2b:4b:b1:                                          3a:81:9d:07:47:eb:45:02:95:79:48:d2:77:23:0b:                                          39:49                                  Exponent:  65537  (0x10001)          Signature  Algorithm:  sha1WithRSAEncrypLon                  42:96:cf:ee:95:c9:62:7c:6c:33:c9:cd:05:80:3c:99:89:32:                  54:fa:5c:3f:83:0c:87:91:f3:95:23:10:61:7c:ae:18:43:4f:                  9e:36:60:dd:bf:60:d0:2d:82:3d:56:dc:f1:cd:25:37:3d:c3:                  bd:c7:74:73:f1:fe:e1:0b:86:56:fc:82:83:71:45:e5:84:6f:                  bb:45:f9:a0:47:11:03:4a:13:7c:ed:15:24:9d:7b:5a:06:13:                  2c:15:ae:1e:98:c5:5e:cc:22:a9:2f:77:ca:2f:a7:~:82:b2:                  09:38:9d:dd:95:6e:65:e3:2b:10:e4:63:fe:30:04:b4:62:10:                  66:97:a3:ea:3d:ce:ef:83:e2:05:03:f1:7a:78:f3:6c:6c:75:                  72:f7:55:b0:3a:58:a5:4d:e7:f9:30:f8:3b:97:36:ad:fc:bc:                  93:90:de:b7:e8:bd:2d:25:5d:20:13:0b:5d:c7:64:ff:65:43:                  1b:3d:d8:5d:9f:ee:03:b7:81:a6:a9:39:ea:3a:cd:00:e2:48:                  de:2b:df:cb:76:74:45:ad:8c:00:ce:ec:06:55:5e:93:7c:68:                  3b:2f:48:e1:72:ed:1d:6e:45:33:12:b2:97:71:74:07:5d:4d:                  bd:0f:ff:c5:10:d9:fa:22:63:ab:9e:a0:44:33:c4:0f:e9:09:   2012  Real-­‐Time  InnovaLons,  Inc.    -­‐    All  rights  reserved   6/25/12   ©   63                  5d:b6:d8:05  

×