Your	  systems.	  Working	  as	  one.	  DDS	  SECURITY	  4rd	  Revised	  Submission	  (Joint)	  mars/2013-­‐03-­‐10	  Doc	...
Agenda	    •  Status	  recap	    •  Summary	  of	  submission	    •  What	  has	  changed?	    •  Some	  details	    •  St...
Status	  recap	    •  Started	  with	  two	  separate	  submissions	  by	  RTI	       and	  PrismTech	                –  R...
Agenda	    •  Status	  recap	    •  Summary	  of	  submission	    •  What	  has	  changed?	    •  How	  the	  submission	 ...
Intro	  to	  DDS	  Security	  and	  scope	  of	           this	  specificaKon	  3/21/13	                ©	  2012	  Real-­‐T...
Security	  as	  a	  system	  problem	                    •  UlKmately	  security	  is	  a	  system	  property	            ...
Three	  security	  boundaries	      Ul:mately	  you	  need	  to	  implement	  the	  3	  of	  them	    •  Boundary	  securi...
Fine-­‐Grained	  Data-­‐Centric	  Security	                                                   Topics	    •  Access	  contr...
Threats	  Alice:	  Allowed	  to	  publish	  topic	  T	                                                       1.           ...
Data-­‐centric/mulKcast	  Insider	  Threats	  	    •  Two	  insider	  threats	  affecKng	  (mulKcast)	  data-­‐     centric...
Reader	  mis-­‐behaves	  as	  unauthorized	        writer	  •  SituaKon:	        –       Alice	  -­‐	  	  creates	  a	  Cr...
Summary	  of	  RFP	  requirements	  3/21/13	             ©	  2012	  Real-­‐Time	  InnovaKons,	  Inc.	  	  -­‐	  	  All	  r...
RFP	  Mandatory	  Requirements	  Proposals	  shall	  define	  …	    6.5.1	  	  …	  a	  Plaoorm	  Independent	  Security	  M...
Mandatory	  Requirements	  6.5.1:	      Security	  Model	  The	  Security	  Model	  for	  DDS	  shall	  …	     6.5.1.1	  	...
Mandatory	  Requirements	  6.5.2:	  	      Set	  of	  IntercepKon	  Points	  and	  SPIs	  The	  Plugin	  SPIs	  shall	  …	...
RFP	  OpKonal	  Requirements	  Proposals	  may	  define	  authorizaKon	  policies	  that	  control	  	  …	    6.6.1	  …	  t...
Summary	  of	  DDS	  Security	  spec.	  3/21/13	              ©	  2012	  Real-­‐Time	  InnovaKons,	  Inc.	  	  -­‐	  	  Al...
Submission	  Guiding	  Principles	  •  Performance	  &	  Scalability	          –  Do	  not	  impact	  parts	  of	  the	  s...
Audience	  and	  Purpose	  for	  this	  SpecificaKon	   •  Audience:	          –  DDS	  vendors/implementers,	  not	  the	 ...
DDS	  Security	  covers	  4	  related	  concerns	                                  Security	  Model	          Security	  P...
Security	  Model	  3/21/13	             ©	  2012	  Real-­‐Time	  InnovaKons,	  Inc.	  	  -­‐	  	  All	  rights	  reserved	...
MR#	  6.5.1	    Security	  Model	    •  A	  security	  model	  is	  defined	  in	  terms	  of:	                –  The	  sub...
Security	  Model	  Example:	      UNIX	  FileSystem	  (simplified)	  •  Subjects:	  	  Users,	  specifically	  processes	  e...
MR#	  6.5.1	      DDS	  Security	  Model	  •  Subjects:	  	  DDS	  DomainParKcipant	  (ParKcipant	  GUID)	  •  Protected	 ...
MR#	  6.5.1	  Mapping	  of	  DDS	  API	  to	  protected	  operaKons	  DDS	  API	  Call	  	                                ...
DDS	  &	  RTPS	  Support	  for	  Security	  3/21/13	               ©	  2012	  Real-­‐Time	  InnovaKons,	  Inc.	  	  -­‐	  ...
Support	  for	  Security	  in	  DDS	  &	  RTPS	    •  DDS	  ParKcipants	  need	  to	  exchange	  security	       informaKo...
Security	  informaKon	  propagated	  via	  DDS	       discovery	                struct	  Property	  {	                    ...
Security	  informaKon	  exchanged	  via	  BuilKnParKcipantMessageWriter	   typedef	  Token	  CryptoToken;	   sequence<Cryp...
BuilKnParKcipantMessageWriter	  typedef	  	  octet	  GuidPrefix_t[12];	  typedef	  	  octet	  Par:cipantMessageDataKind[4];...
Background:	  RTPS	       RTPS	  Message	                          RTPS	  SubMessage	        RTPS	  Header	               ...
Cryptographic	  SPI	  at	  the	  wire-­‐protocol	  level	                                                                 ...
RTPS	  Header	                                        RTPS	  Header	  RTPS	  SubMessage	                                  ...
RTPS	  Header	                                             RTPS	  Header	                           encode_datawriteRTPS	 ...
RTPS	  Header	       encode_rtps_message	          RTPS	  Header	  RTPS	  SubMessage	                               RTPS	 ...
RTPS	  Header	       encode_rtps_message	                           RTPS	  Header	  RTPS	  SubMessage	                    ...
Security	  Plugins	  3/21/13	              ©	  2012	  Real-­‐Time	  InnovaKons,	  Inc.	  	  -­‐	  	  All	  rights	  reserv...
Plaoorm	  Independent	  IntercepKon	  Pts	  +	  	  SPIs	  	                                                               ...
Plaoorm	  Independent	  SPIs	  	  MR#	  6.5.2	  3/21/13	     ©	  2012	  Real-­‐Time	  InnovaKons,	  Inc.	  	  -­‐	  	  All...
MR#	  6.5.3	        BuilKn	  Plugins	  SPI	               Buil:n	  Plungin	                                               ...
MR#	  6.5.4	    Mapping	  to	  DDS	  Language	  PSMs	  	    •  Plugin	  SPIs	  to	  be	  defined	  using	  IDL	    •  IDL-­...
Use	  of	  DDS	  Interoperability	  Protocol	                                                                             ...
Agenda	    •  Status	  recap	    •  Summary	  of	  submission	    •  What	  has	  changed?	    •  Some	  details	    •  St...
What	  has	  changed	    •  Unified	  Token	  representaKons	                –  All	  Tokens	  use	  common	  data-­‐type	 ...
Agenda	    •  Status	  recap	    •  Summary	  of	  submission	    •  What	  has	  changed?	    •  Some	  details	    •  St...
Tokens	  are	  a	  generic	  mechanism	  to	  pass	  informaKon	  between	  DDS	  and	  SPIs	  Token	  interpretaKon	  defi...
Token	  RepresentaKon	     typedef string<> TokenClass;   typedef string<> TokenWrappingClass;   struct DDS_Property {    ...
AuthenKcaKon	  3/21/13	          ©	  2012	  Real-­‐Time	  InnovaKons,	  Inc.	  	  -­‐	  	  All	  rights	  reserved	     48...
AuthenKcaKon	  SPI	                                                                                                 MR#	  ...
MR#	  6.5.2	                                                                                                              ...
BuilKn	  	  DDS:Auth:PKI-­‐DSA-­‐DH	  	  •  Uses	  shared	  CerKficate	  Authority	  (CA)	            –  All	  ParKcipants	...
ConfiguraKon	  of	  Auth:PKI-­‐DS-­‐DH	    •  Three	  things:	                –  X.509	  cerKficate	  that	  defines	  the	  ...
Behavior	  of	  Auth:PKI-­‐DS-­‐DH	    •  validate_local_parKcipant	                –  IdenKtyCredenKalToken	  has	  X.509...
Remote	  ParKcipant	  AuthenKcaKon	  ParKcipants	  receive	  X.509	  Cert	  of	  remote	  parKcipant	  via	  discovery	   ...
Remote	  ParKcipant	  AuthenKcaKon	  Each	  ParKcipant	  calls	  validate_remote_idenKty()	  this	  checks	  remote	  X.50...
Remote	  ParKcipant	  AuthenKcaKon	  ParKcipant1	  creates	  CHALLENGE1	  =	  “CHALLENGE:<nonce>	  and	  sends	  message	 ...
Remote	  ParKcipant	  AuthenKcaKon	  ParKcipant2	  creates	  CHALLENGE2	  :=	  CHALLENGE:<nonce>	  ParKcipant2	  	  sends	...
Remote	  ParKcipant	  AuthenKcaKon	  Part1	  verifies	  SIGN(CHALLENGE1)	  using	  Part2’s	  PK	  Part1	  	  computes	  a	 ...
Remote	  ParKcipant	  AuthenKcaKon	  Part2	  verifies	  SIGN(CHALLENGE2)	  using	  Part1’s	  PK	  Part2	  	  decrypts	  Sha...
Access	  Control	  3/21/13	              ©	  2012	  Real-­‐Time	  InnovaKons,	  Inc.	  	  -­‐	  	  All	  rights	  reserved...
MR#	  6.5.2	                                                                                                        Access...
BuilKn	  	  DDS:AC:PKI	  	  SPI	  •  Configured	  with:	            –  X.509	  CerKficate	  of	  shared	  Permissions	  CA	 ...
Example	  Permissions	  3/21/13	     ©	  2012	  Real-­‐Time	  InnovaKons,	  Inc.	  	  -­‐	  	  All	  rights	  reserved	   ...
Cryptographic	  3/21/13	            ©	  2012	  Real-­‐Time	  InnovaKons,	  Inc.	  	  -­‐	  	  All	  rights	  reserved	    ...
Cryptographic	  3/21/13	     ©	  2012	  Real-­‐Time	  InnovaKons,	  Inc.	  	  -­‐	  	  All	  rights	  reserved	     65	  
MR#	  6.5.3	    Crypto-­‐AES-­‐CTR-­‐HMAC-­‐DSA-­‐DH	    •  EncrypKon	  uses	  AES	  in	  counter	  mode	                –...
BuilKn	  	  DDS:Crypto-­‐AES-­‐CTR-­‐HMAC-­‐DSA-­‐   DH	  SPI	  •  Shared	  secret	  used	  to	  create	  a	  KeyExchangeK...
Conclusion	  •  Submission	  revised	  based	  on	  addiKonal	     implementaKon	  experience	  •  Plugin	  APIs	  modified...
Find	  out	  more…	       www.rK.com	                                                                   dds.omg.org	      ...
Upcoming SlideShare
Loading in...5
×

OMG DDS Security. 4th Revised Submission

1,248

Published on

DDS Security: Fourth revised submission to the OMG Data Distribution Service (DDS) Security Specification.

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

No Downloads
Views
Total Views
1,248
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
35
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

OMG DDS Security. 4th Revised Submission

  1. 1. Your  systems.  Working  as  one.  DDS  SECURITY  4rd  Revised  Submission  (Joint)  mars/2013-­‐03-­‐10  Doc  num:  mars/2013-­‐03-­‐10   SubmiRers:  SpecificaKon  lead:   Real-­‐Time  InnovaKons,  Inc.  Gerardo  Pardo-­‐Castellote,  Ph.D.   PrismTech  Corp.  CTO,  Real-­‐Time  InnovaKons,  Inc.   eProsima  (supporter)   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved  
  2. 2. Agenda   •  Status  recap   •  Summary  of  submission   •  What  has  changed?   •  Some  details   •  Status  &  Conclusion  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   2  
  3. 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  discussed  on  the  use  of  technologies   such  as  (MIKEY  /  SRTP)  to  support  the  needs  of   secure  DDS   •  As  of  the  December  2012  meeKng  PrismTech   joined  the  RTI  submission  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   3  
  4. 4. Agenda   •  Status  recap   •  Summary  of  submission   •  What  has  changed?   •  How  the  submission  allows  a  specializaKon  to   use  MIKEY  and  SRTP   •  Status  &  Conclusion  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   4  
  5. 5. Intro  to  DDS  Security  and  scope  of   this  specificaKon  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   5  
  6. 6. Security  as  a  system  problem   •  UlKmately  security  is  a  system  property   –  Involves  hardware,  so`ware,  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  &  so`ware   configuraKon   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   6  
  7. 7. 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  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   7  
  8. 8. Fine-­‐Grained  Data-­‐Centric  Security   Topics   •  Access  control  per  Topic   •  Read  versus-­‐write  permissions   •  Field-­‐specific  permissions  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   8  
  9. 9. 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     3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   9  
  10. 10. 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    3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   10  
  11. 11. 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  aRack  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/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   11  
  12. 12. Summary  of  RFP  requirements  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   12  
  13. 13. 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   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   13  
  14. 14. 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   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   14  
  15. 15. 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   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   15  
  16. 16. 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.   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   16  
  17. 17. Summary  of  DDS  Security  spec.  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   17  
  18. 18. 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.   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   18  
  19. 19. 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   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   19  
  20. 20. DDS  Security  covers  4  related  concerns   Security  Model   Security  Plugin   DDS  &  RTPS  support   APIs  &  Behavior   for  Security   Buil:n  Plugins   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   20  
  21. 21. Security  Model  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   21  
  22. 22. 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  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   22  
  23. 23. 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   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   23  
  24. 24. 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   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   24  
  25. 25. 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   3/21/13  Protocol.receive_dispose   Topic.dispose_instance   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   25  
  26. 26. DDS  &  RTPS  Support  for  Security  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   26  
  27. 27. Support  for  Security  in  DDS  &  RTPS   •  DDS  ParKcipants  need  to  exchange  security   informaKon   –  CerKficates  for  AuthenKcaKon  &  Permissions   –  Handshake  messages  for  mutual  authenKcaKon  and   shared-­‐secret  establishment   –  KeyTokens  for  key-­‐exchange   •  These  messages  reuse  exisKng  DDS  mechanisms   –  Discovery  topics   –  BuilKn  data  readers  /  writers   •  EncrypKon  and  signatures  introduce  new  RTPS   Submessage  and  Submessage  elements   –  SecureSubMessage   –  SecuredData  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   27  
  28. 28. Security  informaKon  propagated  via  DDS   discovery   struct  Property  {          string<>  name;  2  addiKonal  aRributes  added          string<>  value;   to   };   typedef  sequence<Property>   ParKcipantBuilKnTopicData:          PropertySeq;   struct  Token  {  IdenKtyToken  idenKty;          string<>  token_classid;  PermissionsToken  permissions;          string<>  wrapper_classid;          PropertySeq  properKes;          sequence<octet>  value;          sequence<octet>  wrapped_value;   };     typedef  Token  Iden:tyToken;   typedef  Token  PermissionsToken;   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   28  
  29. 29. Security  informaKon  exchanged  via  BuilKnParKcipantMessageWriter   typedef  Token  CryptoToken;   sequence<CryptoToken>  CryptoTokenSeq;   4  addiKonal  kinds:   KIND_SECURITY_AUTH_HANDSHAKE   KIND_SECURITY_PARTICIPANT_CRYPTO_TOKENS  struct  CryptoTokensMsg  {   KIND_SECURITY_DATAWRITER_CRYPTO_TOKENS          octet  sending_guid[16];   KIND_SECURITY_DATAREADER_CRYPTO_TOKENS          octet  receiving_guid[16];          CryptoTokenSeq  crypto_tokens;  };  typedef  Token                                                HandshakeTokenMsg;  typedef  CryptoTokensMsg    Par:cipantCryptoTokensMsg;  typedef  CryptoTokensMsg    DatawriterCryptoTokensMsg;  typedef  CryptoTokensMsg    DatareaderCryptoTokensMsg;   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   29  
  30. 30. BuilKnParKcipantMessageWriter  typedef    octet  GuidPrefix_t[12];  typedef    octet  Par:cipantMessageDataKind[4];  struct  Par:cipantMessageData  {            GuidPrefix_t  par:cipantGuidPrefix;  //@Key          Par:cipantMessageDataKind        kind;  //@Key          sequence<octet>  data;  };   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   30  
  31. 31. Background:  RTPS   RTPS  Message   RTPS  SubMessage   RTPS  Header   SubMsg  Header  RTPS  SubMessage   SubMsg  Element  RTPS  SubMessage   SubMsg  Element  RTPS  SubMessage   SerializedData  RTPS  SubMessage  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   31  
  32. 32. Cryptographic  SPI  at  the  wire-­‐protocol  level   Message  TransformaKon   RTPS  Header   RTPS  Header   RTPS  SubMessage   RTPS  SubMessage  (*)   Secure  encoding   RTPS  SubMessage  (*)   SerializedData   RTPS  SubMessage   RTPS  SubMessage   Secure  decoding   SecuredData   SerializedData   SerializedData   RTPS  SubMessage  (*)   RTPS  SubMessage   SecuredData   SerializedData   ©  2012  RTI  •  UNCLASSIFIED  •  PROPRIETARY  
  33. 33. RTPS  Header   RTPS  Header  RTPS  SubMessage   RTPS  SubMessage   encode_seriali SerializedData   zed_data   SecuredData   SerializedData  RTPS  SubMessage   RTPS  SubMessage  
  34. 34. RTPS  Header   RTPS  Header   encode_datawriteRTPS  SubMessage   r_submessage   RTPS  SecureSubMsg   RTPS  SubMessage  RTPS  SubMessage   RTPS  SubMessage   RTPS  Header   RTPS  Header   encode_dataread RTPS  SecureSubMsg  RTPS  SubMessage   er_submessage   RTPS  SubMessage  RTPS  SubMessage   RTPS  SubMessage  
  35. 35. RTPS  Header   encode_rtps_message   RTPS  Header  RTPS  SubMessage   RTPS  SecureSubMsg   RTPS  SubMessage  RTPS  SubMessage   RTPS  SubMessage  RTPS  SubMessage   RTPS  SubMessage  
  36. 36. RTPS  Header   encode_rtps_message   RTPS  Header  RTPS  SubMessage   RTPS  SecSubMsg   enco de_d RTPS  SecSubMsg   SerializedData   enco ataw de_s riter_ eriali su b m zed_d essag RTPS  SubMessage   ata   e  RTPS  SubMessage   SecuredData   SerializedData   SerializedData   RTPS  SecSubMsg   RTPS  SubMessage   SecuredData   SerializedData  
  37. 37. Security  Plugins  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   37  
  38. 38. 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 3/21/13   Add a data ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   tag for each data sample 38  
  39. 39. Plaoorm  Independent  SPIs    MR#  6.5.2  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   39  
  40. 40. MR#  6.5.3   BuilKn  Plugins  SPI   Buil:n  Plungin   Notes  AuthenKcaKon   DDS:Auth:PKI-­‐RSA/DSA-­‐DH     Uses  PKI  with  a  pre-­‐configured  shared   CerKficate  Authority.   DSA  and  Diffie-­‐Hellman  for  authenKcaKon   and  key  exchange   Establishes  shared  secret  AccessControl   DDS:Access:PKI-­‐Signed-­‐ Permissions  document  signed  by  shared   XML-­‐Permissions     CerKficate  Authority  Cryptography   DDS:Crypto:AES-­‐CTR-­‐ Protected  key  distribuKon   HMAC-­‐RSA/DSA-­‐DH     AES128  and  AES256    for  encrypKon  (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   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   40  
  41. 41. 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  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   41  
  42. 42. 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]   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   42  
  43. 43. Agenda   •  Status  recap   •  Summary  of  submission   •  What  has  changed?   •  Some  details   •  Status  &  Conclusion  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   43  
  44. 44. 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)  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   44  
  45. 45. Agenda   •  Status  recap   •  Summary  of  submission   •  What  has  changed?   •  Some  details   •  Status  &  Conclusion  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   45  
  46. 46. Tokens  are  a  generic  mechanism  to  pass  informaKon  between  DDS  and  SPIs  Token  interpretaKon  defined  by  SPI  ImplementaKons  Some  tokens  are  propagated  via  DDS   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   46  
  47. 47. 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; }; 3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   47  
  48. 48. AuthenKcaKon  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   48  
  49. 49. AuthenKcaKon  SPI   MR#  6.5.2   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   49  
  50. 50. MR#  6.5.2   Meta-­‐Protocol  to   handshake  and   AuthenKcaKon   establish  shared  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   Behavior   secret   50  
  51. 51. 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.   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   51  
  52. 52. 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.  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   52  
  53. 53. 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  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   53  
  54. 54. Remote  ParKcipant  AuthenKcaKon  ParKcipants  receive  X.509  Cert  of  remote  parKcipant  via  discovery   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   54  
  55. 55. Remote  ParKcipant  AuthenKcaKon  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   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   55  
  56. 56. Remote  ParKcipant  AuthenKcaKon  ParKcipant1  creates  CHALLENGE1  =  “CHALLENGE:<nonce>  and  sends  message  via  ParKcipantMessageWriter  with  MessageToken  :=  {CHALLENGE1}   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   56  
  57. 57. Remote  ParKcipant  AuthenKcaKon  ParKcipant2  creates  CHALLENGE2  :=  CHALLENGE:<nonce>  ParKcipant2    sends  to  ParKcipant1  message  with    MessageToken  :=  {SIGN(CHALLENGE1),  CHALLENGE2}   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   57  
  58. 58. Remote  ParKcipant  AuthenKcaKon  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.   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   58  
  59. 59. Remote  ParKcipant  AuthenKcaKon  Part2  verifies  SIGN(CHALLENGE2)  using  Part1’s  PK  Part2    decrypts  SharedSecret  using  its  own  PK  We  have  Mutual  Authen:ca:on  and  a  SharedSecret   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   59  
  60. 60. Access  Control  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   60  
  61. 61. MR#  6.5.2   Access  Control  SPI  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   61  
  62. 62. 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  idenKty  established  by   the  AuthenKcaKonPlugin   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   62  
  63. 63. Example  Permissions  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   63  
  64. 64. Cryptographic  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   64  
  65. 65. Cryptographic  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   65  
  66. 66. 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  exchange  3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   66  
  67. 67. 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.   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   67  
  68. 68. 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   –  Examine  is  there  are  special  rules  that  affects  ParKKons  •  TargeKng  June  2013  for  vote  to  recommend  adopKon   3/21/13   ©  2012  Real-­‐Time  InnovaKons,  Inc.    -­‐    All  rights  reserved   68  
  69. 69. Find  out  more…   www.rK.com   dds.omg.org   community.rK.com   www.omg.org   demo.rK.com   www.youtube.com/realKmeinnovaKons   blogs.rK.com   www.twiRer.com/RealTimeInnov   www.facebook.com/RTIso`ware   www.slideshare.net/GerardoPardo   ©  2012  RTI  •  ALL  RIGHTS  RESERVED   69  
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×