WSO2Con 2013 - WSO2 as a Crypto Platform


Published on

A Crypto SOA Platform with WSO2

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

WSO2Con 2013 - WSO2 as a Crypto Platform

  1. 1. WSO2  as  a  Crypto  Services  Pla4orm   By  Roger  CARHUATOCTO  |  @Chilcano    
  2. 2. 1.  Abstract  As  Internet  transacBons  increase  in  value,  the  opportunity  to  intercept,  hijack,  and  maliciously  modify  messages  grows.  While  the  OASIS  Digital  Signature  Service  Standard  has  existed  for  five  years,  protecBng  transacBons  using  the  standard  is  oNen  difficult.  A  Cryptographic  Services  Pla4orm  delivers  a  service  set  assuring  integrity,  authenBcity  and  confidenBality  of  transacBons  over  the  Internet.    In  this  session,  I  will  present  a  the  construcBon  of  a  cryptographic  services  pla4orm  using  WSO2  middleware,  and  how  the  pla4orm  delivers  security  mediaBon  between  a  Liferay  Portal  and  a  CerBficaBon  Authority  or  Crypto  Service  Provider.  
  3. 3. 2.  Overview  (1/2)  •  The  trend  is  to  bring  applicaBons  to  more  open  and  centralized   environments.  •  The  business  logic  transcends  physical  boundaries  of  the   organizaBon  and  oNen  have  interfaces  to  interact  with  external   systems.  •  With  so  much  diversity  of  interacBons,  clients,  servers,  and   heterogeneous  systems  must  ensure  trust  and  security  at  all   points  of  interacBon  and  transacBon.  
  4. 4. 2.  Overview  (2/2)  •  For  these  reasons  is  required  end-­‐to-­‐end  security.  From  the   client  to  the  server  covering  all  unsafe  areas.   Security  Context   Security  Context   Client   Canal  of   Business   Web  Service   Requester   CommunicaBon   ApplicaBons  
  5. 5. 3.  The  requeriments  (1/2)   •  Assure  trust  and  security  across  of  criBcal  business  processes.   •  End-­‐to-­‐end  Security   1.-­‐  Fundamental  Principles  (ConfidenBality,   Integrity,  Availability)   2.-­‐  AuthenBcaBon  Requeriments   Security   3.-­‐  AuthorizaBon   Principles   4.-­‐  Accountability   5.-­‐  Non  RepudiaBon  
  6. 6. 3.  The  requeriments  (2/2)  •  What  kind  of  App  require  security?   •  E-­‐Invoice,  DigiBzaBon  CerBfied,  Secure  NoBficaBon,  Long  Term  Data  Archiving,  e-­‐DNI,    e-­‐Payment,   *any*…   Security  Context   Security  Context   Client   Canal  of   Business   Web  Service   Requester   CommunicaBon   ApplicaBons   Security  Context   Client   Canal  of   Business   Web  Service   Requester   CommunicaBon   ApplicaBons   Trusted  Third   Party  
  7. 7. 3.1.  CIA:  ConfidenBality  •  ConfidenBality  is  the  term  used  to  prevent  the  disclosure  of  informaBon   to  unauthorized  individuals  or  systems.  Example:   •  A  credit  card  transacBon  on  the  Internet  requires  the  credit  card   number  to  be  transmiced  from  the  buyer  to  the  merchant  and   from  the  merchant  to  a  transacBon  processing  network.     •  The  system  acempts  to  enforce  confidenBality  by  encrypBng  the   card  number  during  transmission,  by  limiBng  the  places  where  it   might  appear  (in  databases,  log  files,  backups,  printed  receipts,  and   so  on),  and  by  restricBng  access  to  the  places  where  it  is  stored.     •  If  an  unauthorized  party  obtains  the  card  number  in  any  way,  a   breach  of  confidenBality  has  occurred.  •  ConfidenBality  is  necessary  (but  not  sufficient)  for  maintaining  the   privacy  of  the  people  whose  personal  informaBon  a  system  holds.  
  8. 8. 3.2.  CIA:  Integrity   •  In  informaBon  security,  integrity  means  that  data  cannot  be   modified  undetectably.     •  This  is  not  the  same  thing  as  referenBal  integrity  in  databases,   although  it  can  be  viewed  as  a  special  case  of  Consistency  as   understood  in  the  classic  ACID  model  of  transacBon  processing.     •  Integrity  is  violated  when  a  message  is  acBvely  modified  in   transit.  InformaBon  security  systems  typically  provide  message   integrity  in  addiBon  to  data  confidenBality.  
  9. 9. 3.3.  CIA:  Availability   For  any  informaBon  system  to  serve  its  purpose,  the  informaBon   must  be  available  when  it  is  needed.  This  means  that  the  compuBng   systems  used  to  store  and  process  the  informaBon,  the  security   controls  used  to  protect  it,  and  the  communicaBon  channels  used  to   access  it  must  be  funcBoning  correctly.  High  availability  systems  aim   to  remain  available  at  all  Bmes,  prevenBng  service  disrupBons  due  to   power  outages,  hardware  failures,  and  system  upgrades.  Ensuring   availability  also  involves  prevenBng  denial-­‐of-­‐service  acacks.  
  10. 10. 3.4.  AuthenBcaBon  AuthenBcaBon  is  the  establishment  and  verificaBon  of  user  idenBty.  AuthenBcaBon  (from  Greek:  αὐθεντικός;  real  or  genuine,  from  αὐθέντης  authentes;  author)  is  the  act  of  confirming  the  truth  of  an  acribute  of  a  datum  or  enBty.  This  might  involve  confirming  the  idenBty  of  a  person  or  soNware  program,  tracing  the  origins  of  an  arBfact,  or  ensuring  that  a  product  is  what  its  packaging  and  labeling  claims  to  be.  AuthenBcaBon  oNen  involves  verifying  the  validity  of  at  least  one  form  of  idenBficaBon.  
  11. 11. 3.5.  AuthorizaBon  AuthorizaBon  is  the  granBng  of  permission  to  access  specific  informaBon  and  carry  out  specific  acBons    AuthorizaBon  (also  spelt  AuthorisaBon)  is  the  funcBon  of  specifying  access  rights  to  resources,  which  is  related  to  informaBon  security  and  computer  security  in  general  and  to  access  control  in  parBcular.  More  formally,  "to  authorize"  is  to  define  access  policy.  For  example,  human  resources  staff  are  normally  authorized  to  access  employee  records,  and  this  policy  is  usually  formalized  as  access  control  rules  in  a  computer  system.  During  operaBon,  the  system  uses  the  access  control  rules  to  decide  whether  access  requests  from  (authenBcated)  consumers  shall  be  approved  (granted)  or  disapproved  (rejected).  Resources  include  individual  files  or  items  data,  computer  programs,  computer  devices  and  funcBonality  provided  by  computer  applicaBons.  Examples  of  consumers  are  computer  users,  computer  programs  and  other  devices  on  the  computer.  
  12. 12. 3.6.  Accountability  •  Accountability  is  the  ability  to  Be  acBons  to  users    •  Accountability  is  important  for  audiBng  purposes  (provides  traceability,  can   be  used  to  show  compliance  with  regulaBons  or  standards)    •  Non-­‐repudiaBon  is  a  special  case  of  accountability:     •  Ensures  a  party  to  a  transacBon  cannot  deny  its  authenBcity     •  Primary  purpose  is  to  prevent  a  user  from  denying  responsibility  for  a   specific  acBon     •  Establishing  non-­‐repudiaBon  requires  a  high  level  of  trust  in  the   authenBcaBon  credenBals     •  Security  purists  argue  that  sufficient  trust  for  non-­‐repudiaBon  cannot   be  established  without  external  cerBficaBon  of  idenBty    
  13. 13. 3.7.  Non  RepudiaBon  In  law,  non-­‐repudiaBon  implies  ones  intenBon  to  fulfill  their  obligaBons  to  a  contract.  It  also  implies  that  one  party  of  a  transacBon  cannot  deny  having  received  a  transacBon  nor  can  the  other  party  deny  having  sent  a  transacBon.  Electronic  commerce  uses  technology  such  as  digital  signatures  and  public  key  encrypBon  to  establish  authenBcity  and  non-­‐repudiaBon.  
  14. 14. 4.  OrganizaBons  for  XML  Standards   WS-­‐*   World     Wide     Web     XML   Consor-um   Internet     Engineering     PKIX   Task     Force  
  15. 15. 5.  XML  Security  Standards  overview  1 4 7 SAML  (Security   XML-­‐DSIG  (XML  Digital   DSS  (Digital  Signature   AsserBon  Markup   Signature)   Services)   Language)  2 5 8 XACML  (eXtensible   XAdES  (XML  Advanced   PKIX  (Public-­‐Key   Access  Control  Markup   Electronic  Signatures)     Infrastructure  -­‐  X.509)   Language)    3 6 WS-­‐Security   XML-­‐ENC  (XML   It  is  not  XML,  but   EncrypBon)   who  does  not  use  it?  
  16. 16. 5.1.  XML  Security  Standards  overview   XML-­‐based  framework  for   How  is  used:  SAML  (Security   communicaBng  user  authenBcaBon,  enBtlement,   •  Web  Single  Sign-­‐On  AsserBon  Markup   and  acribute  informaBon.  As  its  name  suggests,   SAML  allows  business  enBBes  to  make  asserBons   •  Acribute-­‐Based  AuthorizaBon   •  Securing  Web  Services  Language)   regarding  the  idenBty,  acributes,  and  enBtlements   of  a  subject  (an  enBty  that  is  oNen  a  human  user)   •  Federated  idenBty   to  other  enBBes,  such  as  a  partner  company  or   Other  standards  related:   another  enterprise  applicaBon.   •  Liberty  Alliance:  IdenBty  FederaBon  Framework  hcp://www.oasis-­‐ (ID-­‐FF).  security   •  Shibboleth   •  XACML   •  WS-­‐Security  
  17. 17. 5.2.  XML  Security  Standards  overview   The  standard  defines  a  declaraBve  access  control   How  is  used:  XACML  (eXtensible   policy  language,  a  request/response  language   •  XACML  is  primarily  an  Acribute  Based  Access  Access  Control  Markup   implemented  in  XML  for  describing  how  to   evaluate  authorizaBon  requests  according  to  the   Control  system  (ABAC).   •  Role-­‐based  access  control  (RBAC)  can  also  be  Language)     rules  defined  in  policies.   The  policy  language  is  used  to  express  access   implemented  in  XACML  as  a  specializaBon  of   ABAC.   control  policies  ("who  can  do  what  when").  hcp://www.oasis-­‐ Other  standards  related:  xacml   •  SAML  
  18. 18. 5.3.  XML  Security  Standards  overview   The  protocol  specifies  how  integrity  and   How  is  used:  WS-­‐Security   confidenBality  can  be  enforced  on  messages  and   •  End-­‐to-­‐end  security   allows  the  communicaBon  of  various  security   •  Non-­‐RepudiaBon   token  formats,  such  as  SAML,  Kerberos,  and  X.509.     •  AlternaBve  transport  bindings  (i.e.  JMS,  SMTP)     •  Reverse  proxy/common  security  token   Its  main  focus  is  the  use  of  XML  Signature  and  XML   EncrypBon  to  provide  end-­‐to-­‐end  security.   Other  standards  related:   •  XML-­‐DSig  hcp://www.oasis-­‐ •  XML-­‐Enc  wss   •  WS-­‐SecureConversaBon  
  19. 19. 5.4.  XML  Security  Standards  overview   •  Specifies  a  process  for  digitally  signing  data  and   How  is  used:  XML-­‐DSIG  (XML  Digital   represenBng  the  result  in  XML     •  Can  be  used  to  sign  data  (a  resource)  of  any  Signature)   •  Define  the  processing  rules  and  syntax  for  XML   digital  signatures.   type,  typically  XML  documents,  but  anything   that  is  accessible  via  a  URL  can  be  signed.   •  A  serialised  form  in  XML  is  defined  for  the   signature     •  The  signatures  can  be  applied  to  informaBon  in   Other  standards  related:   any  form,  not  just  XML-­‐formaced  informaBon     •  PKCS#7  hcp://   •  SOAP   •  SAML   •  XML-­‐Enc  
  20. 20. 5.5.  XML  Security  Standards  overview   Is  a  set  of  extensions  to  XML-­‐DSig   How  is  used:  XAdES  (XML  Advanced   recommendaBon  making  it  suitable  for  advanced   •  E-­‐Invoicing  Electronic  Signatures)     electronic  signature.   While  XML-­‐DSig  is  a  general  framework  for   •  Secure  Archiving   •  Secure  DigiBzaBon   digitally  signing  documents,  XAdES  specifies   •  Etc.   precise  profiles  of  XML-­‐DSig  for  use  with  advanced   electronic  signature  in  the  meaning  of  European   Other  standards  related:   Union  DirecBve  1999/93/EC.  One  important   •  XML-­‐Dsig  hcp://   benefit  from  XAdES  is  that  electronically  signed   •  CAdES  (CMS  Advanced  Electronic  Signature)   documents  can  remain  valid  for  long  periods,  even   •  PAdES  (PDF  Advanced  Electronic  Signature)   if  underlying  cryptographic  algorithms  are  broken.   •  Trusted  Bmestamping     XAdES  defines  six  profiles  (forms)  differing  in  protecBon  level  offered.  Each  profile  includes  and  extends  the  previous  one:   •  XAdES,  basic  form  just  saBsfying  DirecBve  legal  requirements  for  advanced  signature;   •  XAdES-­‐T  (Bmestamp),  adding  Bmestamp  field  to  protect  against  repudiaBon;   •  XAdES-­‐C  (complete),  adding  references  to  verificaBon  data  (cerBficates  and  revocaBon  lists)  to  the  signed  documents  to   allow  off-­‐line  verificaBon  and  verificaBon  in  future  (but  does  not  store  the  actual  data);   •  XAdES-­‐X  (extended),  adding  Bmestamps  on  the  references  introduced  by  XAdES-­‐C  to  protect  against  possible   compromise  of  cerBficates  in  chain  in  future;   •  XAdES-­‐X-­‐L  (extended  long-­‐term),  adding  actual  cerBficates  and  revocaBon  lists  to  the  signed  document  to  allow   verificaBon  in  future  even  if  their  original  source  is  not  available;   •  XAdES-­‐A  (archival),  adding  possibility  for  periodical  Bmestamping  (e.g.  each  year)  of  the  archived  document  to  prevent   compromise  caused  by  weakening  signature  during  long-­‐Bme  storage  period.  
  21. 21. 5.6.  XML  Security  Standards  overview   •  Specifies  a  process  for  encrypBng  data  and   How  is  used:  XML-­‐ENC  (XML   represenBng  the  result  in  XML  such  that  it  is   •  Privacy  EncrypBon)   only  discernable  to  the  intended  recipients  and   opaque  to  all  others.   •  EncrypBon  of  informaBon   •  The  informaBon  that  is  encrypted  can  be   arbitrary  data  (including  an  XML  document),  an   XML  element,  or  XML  element  content     Other  standards  related:   •  The  result  is  an  XML  EncrypBon  element  that   •  XML-­‐DSig  hcp://   contains  or  idenBfies  the  cipher  data.   •  TLS/SSL   •  PGP  
  22. 22. 5.7.  XML  Security  Standards  overview   •  Describes  two  XML-­‐based  request/response   How  is  used:  DSS  (Digital  Signature   protocols  (a  signing  protocol  and  a  verifying   •  Trusted  Third  Party  (ValidaBon  Systems,  Services)   protocol).     •  Through  these  protocols  a  client  can  send   Archiving,  …)   documents  to  a  server  and  receive  back  a   Other  standards  related:   signature  on  the  documents;  or  send   •  PKI   documents  and  a  signature  to  a  server,  and   •  PKIX   receive  back  an  answer  on  whether  the  hcps://www.oasis-­‐ •  WS-­‐Security   signature  verifies  the  documents.    dss   •  XML-­‐DSign,  XML-­‐Enc  and  XAdES.   •  The  DSS  Core  specificaBons  provide  the  basic   protocols  and  elements  which  are  adapted  to   support  specific  use  cases  in  the  DSS  profiles.   Document   Signing   Verifying  
  23. 23. 5.7.  XML  Security  Standards  overview  DSS  Core:  •  Provides  the  basic  protocols  and  elements  which  are  adapted  to  support  specific  use  cases  in  the  DSS  profiles.  DSS  Profiles:  1.  DSS  Time-­‐stamp  profile  defines  the  use  of  the  DSS  Core  protocols  to  support  creaBon  and  verificaBon  of  Bme-­‐stamps.  The   profile  includes  support  for  the  creaBon  of  XML  Time-­‐stamps  as  defined  in  the  Core  and  binary  Bme-­‐stamps  as  defined  in   RFC  3161.  2.  DSS  Asynchronous  profile  defines  a  simple  mechanism  for  asynchronous  DSS  signing  and  verificaBon  requests.  3.  DSS  Code-­‐signing  profile  defines  the  use  of  the  DSS  Core  protocols  to  support  the  signing  of  a  soNware  program.  4.  DSS  J2ME  Code-­‐signing  profile  defines  the  use  of  the  DSS  Core  protocols  to  support  the  signing  of  a  soNware  program  as   specified  in  the  Java  2  Micro  EdiBon  (J2ME),  Mobile  InformaBon  Device  Profile  2.0.  5.  DSS  EnBty  seal  profile  defines  the  use  of  the  DSS  Core  protocols  to  support  creaBon  and  validaBon  of  a  “seal”  created  by  a   given  EnBty  or  OrganizaBon  on  electronic  data.  6.  DSS  EPM  profile  defines  the  use  of  the  DSS  Core  protocols  to  support  the  Universal  Postal  Union’s  Electronic  PostMarking   (also  called  Digital  PostMark)  service.    7.  DSS  German  Signature  Law  profile  defines  the  use  of  the  DSS  Core  protocols  to  support  creaBon  and  validaBon  of  qualified   signatures  according  to  the  guidelines  given  by  the  German  signature  law.  8.  DSS  AdES  profile  defines  the  use  of  the  DSS  Core  to  support  the  creaBon  and  verificaBon  of  XML  and  binary  Advanced   Electronic  Signatures  as  defined  in  ETSI  TS  101  733  and  TS  101  903.  9.  DSS  Signature  Gateway  profile  defines  the  use  of  the  DSS  Core  to  support  the  transform  of  both  signing  technology  and   credenBal  logisBcs.    
  24. 24. 5.8.  XML  Security  Standards  overview   •  A  public-­‐key  infrastructure  (PKI)  is  a  set  of   How  is  used:  PKIX  (Public-­‐Key   hardware,  soNware,  people,  policies,  and   •  Create  CA,  RA,  e-­‐DNI,  SSL,  Digital  Dignature  of  Infrastructure  -­‐  X.509)   procedures  needed  to  create,  manage,   distribute,  use,  store,  and  revoke  digital   documents,  Sign  SoNware,  …   cerBficates  which  are  used  to  verify  that  a   Other  standards  related:   parBcular  public  key  belongs  to  a  certain  enBty.     •  RSA  PKCS  (Public  Key  Cryptography  Standards)   •  The  PKI  creates  digital  cerBficates  which  map   public  keys  to  enBBes,  securely  stores  these  hcps://   cerBficates  in  a  central  repository,  and  revokes  hcps://   them  if  needed.   •  A  PKI  consists  of:   •  A  cerBficate  authority  (CA)  that  both   issues  and  verifies  the  digital   cerBficates.   •  A  registraBon  authority  which  verifies   the  idenBty  of  users  requesBng   informaBon  from  the  CA.   •  A  central  directory.  For  example  a   secure  locaBon  in  which  to  store  and   index  keys.   •  A  cerBficate  management   system[clarificaBon  needed]   •  A  **cerBficate  policy**  
  25. 25. 6.  FOSS  Crypto  products  1.  eID  DSS   •  Belgium  Federal  ICT  Department  (FedICT)   •  hcps://­‐dss  Supports  the  creaBon  of  XML  signatures  according  to  XAdES-­‐X-­‐L  using  a  browser  POST  protocol  to  navigate  the  web  browser  from  Relying  Party  to  the  eID  DSS.    ANer  verificaBon  of  the  to-­‐be-­‐signed  XML  document  (the  visualizaBon  of  the  XML  structure  can  be  styled  using  XSLT)  the  ciBzen  can  sign  the  XML  structure  using  the  eID  card  via  the  eID  Applet  technology.  ANer  signature  finalizaBon  by  the  eID  DSS  (upgrade  from  XAdES-­‐BES  to  XAdES-­‐X-­‐L  using  the  eID  Trust  Service)  the  eID  DSS  will  navigate  the  web  browser  back  to  the  Relying  Party  where  the  work  flow  can  conBnue.    For  signature  verificaBon  the  Relying  Party  can  use  an  eID  DSS  web  service  according  to  the  OASIS  DSS  specificaBons.  The  eID  DSS  signature  validaBon  web  service  is  using  the  eID  Trust  Service  for  historical  cerBficate  chain  validaBon.  Because  both  the  signature  creaBon  and  signature  validaBon  is  outsourced  to  the  eID  DSS,  the  Relying  Party  does  not  need  to  have  noBon  of  the  actual  used  signature  format.  This  way  the  Relying  Party  can  fully  focus  on  the  business  work  flow  and  define  an  XML  schema  according  to  its  business  needs.  
  26. 26. 6.  FOSS  Crypto  products  2.  Digital  Signature  Service   •  European  Comission  –  Interoperability  SoluBons  for  European  Public   AdministraBons  (ISA)   •  hcp://­‐dss/descripBon    The  DSS  soNware  allows  Member  States  to  create  and  verify  X/CAdES  forms  up  to  the  -­‐A  form  and  PAdES  forms  up  to  LTV  originaBng  from  other  MS  when  used  with  documents.    In  parBcular  it:  •  supports  the  requirements  in  Commission  Decision  2011/130/EU;  •  for  verificaBon  makes  use  of  Member  States  trusted  lists;  •  is  available  under  the  form  of  an  SDK  and  as  a  standalone  applicaBon.  •  allows  easy  use  of  the  MOCCA  adapter  to  increase  the  support  of  Ms  smalrtcards   at  the  signing  aide  
  27. 27. 6.  FOSS  Crypto  products  3.  SignServer:   •  hcp://  •  Is  an  applicaBon  framework  performing  cryptographic  operaBons  for  other  applicaBons.    •  Its  intended  to  be  used  in  environments  where  keys  are  supposed  to  be  protected  in  hardware  but  it  isnt  possible  to  connect  such   hardware  to  exisBng  enterprise  applicaBons  or  where  the  operaBons  are  considered  extra  sensiBve  so  the  hardware  have  to  protected   more  carefully.    •  Another  usage  is  to  provide  a  simplified  method  to  provide  signatures  in  different  applicaBon  managed  from  one  locaBon  in  the   company.    SignServer  has  ready  to  use  modules  for:  •  TimeStamp  Authority  (RFC  3161  compliant)  •  Signers  for  different  documents:  PDF,  XML,  ODF,  OOXML,  MRTD  (ePassport  document  signer)  •  General  purpose  signers:  CMS  •  Validators  for  documents:  XML  •  The  modules  can  be  used  using  HTTP  or  web  services  interfaces.      SignServer  also  contains  funcBons  for:  •  CerBficate  ValidaBon  Service  Framework  for  validaBng  cerBficates  using  CRLs  or  OCSP  •  Different  kinds  of  tokens  can  be  used  to  perform  sign  and  crypto  operaBons:  SoN  token  using  JKS  or  PKCS12  files,  PKCS#11  HSM   tokens,  such  as  the  UBmaco  CryptoServer,  SafeNet  ProtectServer  and  Luna,  nCipher  nShield,  etc.  
  28. 28. 6.  FOSS  Crypto  products  4.  EJBCA:   •  EJBCA  is  an  enterprise  class  PKI  CerBficate  Authority  built   on  JEE  technology.  It  is  a  robust,  high  performance,   pla4orm  independent,  flexible,  and  component  based  CA  to   be  used  stand-­‐alone  or  integrated  in  other  JEE  applicaBons.   •  hcp://        Features:    •  hcp://    •  PKI  features:  MulBple  CAs,  Sub  CAs,  PKIX  compliant,  PKCS  compliant,  …  •  ePassport  PKI  features:  support  for  BAC  PKI,  Country  Signing  CA  (CSCA)  and  Document  Signer  (DS)  cerBficates.   Support  EAC  PKI,  Country  Verifying  CA  (CVCA)  and  Document  Verifiers  (DV)  issuing  InspecBon  System  (IS)   cerBficates.  •  Integra-on  features:  Built  on  the  JEE  5  (EJB  3.0)  specificaBon,  Web  service  (WS)  interface  for  remote   administraBon  and  integraBon.  API  for  an  external  RA,  restricBng  in-­‐bound  traffic  to  CA.  Hard  token  module  for   integraBng  with  hard  token  issuing  system  (smart  cards).  
  29. 29. 6.  FOSS  Crypto  products  5.  The  Sirius  Signing  Server   •  hcp://sirius-­‐   •  hcps://    •  Sirius  Server  is  a  signing  and  verificaBon  soNware  suite  with  its  focus  on  high  throughput  and  easy   integraBon  into  an  exisBng  IT  landscape.  •  In  compliance  with  the  European  Digital  Signature  guidelines  for  signature  creaBon  smartcards  with  OCF   and  PKCS11,  these  interfaces  are  supported  by  the  server.  •  This  open  source  version  supports  soN  cerBficates.    •  A  test  cerBficate  is  provided  within  the  soNware  in  the  sourceforge  repository.    •  An  EJB  container  is  required  and  provided  in  the  repository.    Features:  •  It  implements  the  OASIS  DSS  standard  •  Enable  mass  digital  signing  in  compliance  with  PKCS7  and  XMLDSig  •  J2SE/W3C  widget  code  signing  •  MulBple  import  and  export  interfaces  
  30. 30. 6.  FOSS  Crypto  products  6.  OpenSign   •  Is  a  collecBon  of  Java  Applets  providing  client-­‐side  digital  signing   funcBonality  using  x.509  cerBficates.     •  It  currently  consists  of  two  applets,  one  for  signing  plain  ASCII   text  and  another  providing  login  funcBonality.   •  hcp://  Features:  •  digital  signing  of  text  •  logon  funcBonality  •  support  for  x.509  cerBficates  stored  in  PKCS12s  •  support  for  x.509  cerBficates  stored  in  the  MicrosoN  Windows  Keystore  (CAPI)  •  support  for  the  naBve  MicrosoN  Java  virtual  machine  •  works  in  all  common  browsers:  Firefox,  Internet  Explorer,  Mozilla,  Safari,  etc.  •  has  a  small  footprint:  The  core  applet  is  less  than  100KB.  •  has  localizaBon  support  
  31. 31. 6.  FOSS  Crypto  products  7.  CryptoApplet   •  Is  a  Java  applet  for  advanced  digital  signature  creaBon.   •  hcp://    The  signature  representaBon  formats  supported  by  CryptoApplet  are  the  following:    •  Raw  signature.  •  CMS/PKCS#7.  •  XAdES-­‐X-­‐L  in  DigiDoc  format.  •  PDF  signature.  CerBficate  management  is  done  transparently  for  the  user  through  direct  access  to  CryptoAPI,  if  we  are  using  MicrosoN  Internet  Explorer,  or  to  PKCS#11  if  we  are  using  Firefox  (either  in  Windows  or  GNU/Linux).  Stored  cerBficates  can  also  be  used  if  the  client  system  has  the  Clauer  soNware  installed.    The  applet  can  also  be  executed  in  the  operaBng  systems  MicrosoN  Windows  XP  and  GNU/Linux,  the  only  requirement  being  having  Suns  Java  Virtual  Machine  (version  1.5  o  higher)  installed.  
  32. 32. 6.  FOSS  Crypto  products  8.  Open  eSignForms   •  Is  the  first  free  and  open  source,  web  contracBng  soNware   applicaBon  (on-­‐premise)  and  SaaS  (hosted).   •  hcp://    Open  eSignForms  can  help  your  school,  non-­‐profit,  medical  facility,  or  business  go  green  by  improving  on  your  paperless  acBviBes.  Just  use  any  of  our  free  forms  to  help  with  secure  document  delivery  with  external  parBes  and  e-­‐docs  to  storing  files  and  scanned  paperwork  (fully  encrypted)  for  your  own  secure  access  from  anywhere  in  the  world.  
  33. 33. 6.  FOSS  Crypto  products  9.  OpenXAdES   •  OpenXAdES  is  technology  that  enables  people  to  work  with   legally  binding  digital  signatures.   •  hcp://    OpenXAdES  is:  •  Document  format.  OpenXAdES  specifies  the  format  that  is  used  for  storing  original  signed  documents  (in  any   format),  signatures  given  to  those  documents  and  the  associated  technical  informaBon.  It  is  based  on  the  XML-­‐ DSIG  (XML  Digital  Signatures)  standard  by  W3C  and  XAdES  (XML  Advanced  Electronic  Signatures)  technical   standard  published  by  ETSI  (European  TelecommunicaBon  Standards  InsBtute).  •  Program  libraries.  OpenXAdES  provides  libraries  in  C  and  Java  for  document  creaBon,  signing  and  verificaBon.    OpenXAdES  libraries  are  used  for  end-­‐user  tools  currently  branded  as  "DigiDoc”:  •  Client  program.  DigiDoc  Client  is  a  simple  Windows  client  program  for  working  with  OpenXAdES  documents.  •  Web  portal.  Portal  soNware  is  based  on  the  OpenXAdES  libraries  and  lets  people  work  with  digital  documents   and  signatures  without  the  need  to  install  any  addiBonal  soNware.  Both  the  client  and  the  portal  are  based  on   the  same  OpenXAdES  libraries  that  are  made  available  for  other  developers  in  the  download  area.  DigiDoc   Portal  is  available  for  users  with  Estonian  ID-­‐card.  
  34. 34. 6.  FOSS  Crypto  products  10.  Open-­‐VA   •  hcp://­‐va    
  35. 35. 7.  Architecture  for  Crypto  SOA                Web  Portal   Mobile   B2B  /  B2C   CRYPTO WS Srvc1 Srvc2 Srvc3 Srvc4 Srvc5 Srvc6 Srvc7 Srvc8 Srvc9 Srvc10 Authentication Enterprise Service Bus Activity Authorization Monitoring SSO Identity Mngmt ADAPTERS SRV1 SRV2 SRV3 SRV4 SRV5 SRV6 SOAP REST JMS IDOC FTP JMS CMS ERP CRM BPMCertification -Time Server Hardware Digital Time PDF Secure DigitalAuthority -OCSP Security Signature Stamp Signature Archiving Signature(PKI) Module (HSM) Creator Creator Creator Validator BI Trusted Third Party (TTP) and Cryptography Services Existing and Legacy Apps
  36. 36. 8.  Use  Case#1:  Signing  in  the  client  side   Client/Applet   Liferay/DocLib   WSO2  ESB/Proxy   TTP/Validator   1   User  want  to  sign  a  document  with  his  private  and  public  key   1   stored  in  his  Smart  Card.     2   The  Applet  creates  hash  and  when  are  creaBng  signature,  it   3   2   calls  to  TTP  for  validaBng  keys/cerBficates  (OCSP,  Time  Stamp,   CRL,  …).   4   Liferay  is  a  place  to  store  document,  signed  documents,   5   3   sigantures,  etc.   WSO2  ESB  is  just  a  WS  Proxy.   4   TTP  is  the  validator  of  idenBBes  (keys/cerBficates),  status  of   5   credenBals  (cerBficate  is  or  not  revoked?,  OCSP,  CRL,  …).    Document  Library    ESB    CA,  TSA,  OCSP,  …    Users         TTP  gives  us  a  trust  Bme  (Time  Stamping).      
  37. 37. 9.  Use  Case#2:  Signing  in  the  server  side   Client   Liferay/DocLib   WSO2  ESB/Proxy   TTP/Validator   User  wants  document  to  be  signed.     1   1   User  sends  document  to  be  signed.   2   3   Liferay  receives  the  document  and  save  it,  then  It  calls  to  WSO2   2   ESB  for  creaBng  signature.   WSO2  receives  signing  request  and  It  prepares  the  creaBon  of   4   5   3   signature  (get  Bme  stamp,  validate  keys/cerBficate,  …)   6   4   TTP  sends  informaBon  on  status  of  validaBon  to  WSO2  ESB.     5   WSO2  ESB  creates  signature  if  status  of  validaBon  was  OK.   6   Liferay  receives  the  signed  document,  as  a  repository  document   assures  integrity,  confidenciality  and  privacy.    Users    Document  Library    CA,  TSA,  OCSP,  …          ESB      
  38. 38. 10.  Use  Case#3:  Time  Stamping   Client   Liferay/DocLib   WSO2  ESB/Proxy   TTP/Validator   The  user  wants  to  store  a  document  in  the  repository   1   1   2   Liferay  receives  the  document  and  save  it,  then  It  calls  to  WSO2   2   ESB  for  creaBng  Bme  stamp.     WSO2  receives  Bme  stamping  request  and  re-­‐send  to  TTP.   4   3   In  this  case  WSO2  ESB  is  just  a  Proxy,  but  could  replace  TTP.   5   TTP  sends  Bme  stamping  (signature)  to  Liferay.    WSO2  ESB   4   knows  if  request  was  responded.   Liferay  receives  response  message  (Bme  stamping)  and  saves  it   5   inside.    Users    Document  Library    ESB    CA,  TSA,  OCSP,  …             Atomic  Clock  
  39. 39. DSS.wsdl  
  40. 40. TS  Request  
  41. 41. TS  Response  
  42. 42. 11.  Use  Case#3:  ValidaBon  Time  Stamp  
  43. 43. 12.  Business  Cases   ¤  Any  process  looking   Content   ¤  Cer-fied      for  non-­‐repudia-on  Documents   ¤  Long     ¤  DRM   Digi-za-on  of   Term     Archive    Documents   Archiving   ¤  E-­‐Invoice   ¤  E-­‐Notary   ¤  E-­‐Burofax   ¤  Records     Management   Processes   Workflow  
  44. 44. 13.  Demo  /  Proof  of  Concept   “Document  Time  Stamping”     •   Read  Document   •   Sign  request  with  TSA’s  cerBficate   • Send  request  to  TSA   • Receive  response  and  store  in  DocLib  
  45. 45. 14.  Conclusions  1.  You  need  large  investments  to  ensure  security  on  our  systems?  -­‐  not,  do  not!    •   Exists  standards  •   Exists  crypto  frameworks,  libraries,  etc.  •   Exists  free  open  source  crypto  apps  •   You  can  build  robust  and  secure  ApplicaBons  on  top  of  WSO2  pla4orm  2.  Why  not  use  WSO2  API  to  create  a  Crypto  API.  -­‐  Yes,we  can.  
  46. 46. Thank  you  
  47. 47. Roger  CARHUATOCTO  IT & FOSS Consultant SOA, BPM, ECM, Portal and Security. You can reach me on: roger [AT] +34 629292125 @chilcano