WSO2Con 2013 - WSO2 as a Crypto Platform

WSO2 as a Crypto Services Pla4orm By Roger CARHUATOCTO | @Chilcano

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.

1. Abstract

•  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.

2. Overview (1/2)

•  For these reasons is required end-‐to-‐end security. From the client to the server covering all unsafe areas.

2. Overview (2/2)

Client Requester

Canal of CommunicaBon Web Service Business

ApplicaBons

Security Context Security Context

1.-‐ Fundamental Principles (ConfidenBality, Integrity, Availability)

•  Assure trust and security across of criBcal business processes. •  End-‐to-‐end Security

3. The requeriments (1/2)

Requeriments 2.-‐ AuthenBcaBon

3.-‐ AuthorizaBon

4.-‐ Accountability

5.-‐ Non RepudiaBon

Security Principles

•  What kind of App require security? •  E-‐Invoice, DigiBzaBon CerBfied, Secure NoBficaBon, Long Term Data Archiving, e-‐DNI, e-‐Payment,

*any*…

3. The requeriments (2/2)

Client Requester


ApplicaBons

Trusted Third Party

Security Context

Client Requester


ApplicaBons

Security Context Security Context

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.

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.

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.

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.

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.

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

3.7. Non RepudiaBon

In law, non-‐repudiaBon implies one's 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.

4. OrganizaBons for XML Standards

World Wide Web Consor-um

Internet Engineering Task Force

WS-‐*

XML

PKIX

5. XML Security Standards overview

SAML (Security AsserBon Markup Language)

XACML (eXtensible Access Control Markup Language)

WS-‐Security

XML-‐DSIG (XML Digital Signature)

XAdES (XML Advanced Electronic Signatures)

XML-‐ENC (XML EncrypBon)

DSS (Digital Signature Services)

1

2

3

4

5

6

7

PKIX (Public-‐Key Infrastructure -‐ X.509)

8

It is not XML, but who does not use it?

5.1. XML Security Standards overview

SAML (Security AsserBon Markup Language)

hcp://www.oasis-‐open.org/commicees/security

XML-‐based framework for communicaBng user authenBcaBon, enBtlement, and acribute informaBon. As its name suggests, SAML allows business enBBes to make asserBons regarding the idenBty, acributes, and enBtlements of a subject (an enBty that is oNen a human user) to other enBBes, such as a partner company or another enterprise applicaBon.

How is used: •  Web Single Sign-‐On •  Acribute-‐Based AuthorizaBon •  Securing Web Services •  Federated idenBty

Other standards related: •  Liberty Alliance: IdenBty FederaBon Framework

(ID-‐FF). •  Shibboleth •  XACML •  WS-‐Security

5.2. XML Security Standards overview The standard defines a declaraBve access control policy language, a request/response language implemented in XML for describing how to evaluate authorizaBon requests according to the rules defined in policies. The policy language is used to express access control policies ("who can do what when").

How is used: •  XACML is primarily an Acribute Based Access

Control system (ABAC). •  Role-‐based access control (RBAC) can also be

implemented in XACML as a specializaBon of ABAC.

Other standards related: •  SAML

XACML (eXtensible Access Control Markup Language)

hcp://www.oasis-‐open.org/commicees/xacml

5.3. XML Security Standards overview The protocol specifies how integrity and confidenBality can be enforced on messages and allows the communicaBon of various security token formats, such as SAML, Kerberos, and X.509. Its main focus is the use of XML Signature and XML EncrypBon to provide end-‐to-‐end security.

WS-‐Security

hcp://www.oasis-‐open.org/commicees/wss

How is used: •  End-‐to-‐end security •  Non-‐RepudiaBon •  AlternaBve transport bindings (i.e. JMS, SMTP) •  Reverse proxy/common security token

Other standards related: •  XML-‐DSig •  XML-‐Enc •  WS-‐SecureConversaBon

5.4. XML Security Standards overview •  Specifies a process for digitally signing data and

represenBng the result in XML •  Define the processing rules and syntax for XML

digital signatures. •  A serialised form in XML is defined for the

signature •  The signatures can be applied to informaBon in

any form, not just XML-‐formaced informaBon

XML-‐DSIG (XML Digital Signature)

hcp://www.w3.org/Signature/

How is used: •  Can be used to sign data (a resource) of any

type, typically XML documents, but anything that is accessible via a URL can be signed.

Other standards related: •  PKCS#7 •  SOAP •  SAML •  XML-‐Enc

5.5. XML Security Standards overview Is a set of extensions to XML-‐DSig recommendaBon making it suitable for advanced electronic signature. While XML-‐DSig is a general framework for digitally signing documents, XAdES specifies precise profiles of XML-‐DSig for use with advanced electronic signature in the meaning of European Union DirecBve 1999/93/EC. One important benefit from XAdES is that electronically signed documents can remain valid for long periods, even if underlying cryptographic algorithms are broken.

XAdES (XML Advanced Electronic Signatures)

hcp://www.w3.org/TR/XAdES/

How is used: •  E-‐Invoicing •  Secure Archiving •  Secure DigiBzaBon •  Etc.

Other standards related: •  XML-‐Dsig •  CAdES (CMS Advanced Electronic Signature) •  PAdES (PDF Advanced Electronic Signature) •  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.

5.6. XML Security Standards overview •  Specifies a process for encrypBng data and

represenBng the result in XML such that it is only discernable to the intended recipients and opaque to all others.

•  The informaBon that is encrypted can be arbitrary data (including an XML document), an XML element, or XML element content

•  The result is an XML EncrypBon element that contains or idenBfies the cipher data.

XML-‐ENC (XML EncrypBon)

hcp://www.w3.org/EncrypBon/2001/

How is used: •  Privacy •  EncrypBon of informaBon

Other standards related: •  XML-‐DSig •  TLS/SSL •  PGP

5.7. XML Security Standards overview •  Describes two XML-‐based request/response

protocols (a signing protocol and a verifying protocol).

•  Through these protocols a client can send documents to a server and receive back a signature on the documents; or send documents and a signature to a server, and receive back an answer on whether the signature verifies the documents.

•  The DSS Core specificaBons provide the basic protocols and elements which are adapted to support specific use cases in the DSS profiles.

DSS (Digital Signature Services)

hcps://www.oasis-‐open.org/commicees/dss

How is used: •  Trusted Third Party (ValidaBon Systems,

Archiving, …)

Other standards related: •  PKI •  PKIX •  WS-‐Security •  XML-‐DSign, XML-‐Enc and XAdES.

Signing Verifying

Document

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.

5.8. XML Security Standards overview •  A public-‐key infrastructure (PKI) is a set of

hardware, soNware, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital cerBficates which are used to verify that a parBcular public key belongs to a certain enBty.

•  The PKI creates digital cerBficates which map public keys to enBBes, securely stores these cerBficates in a central repository, and revokes 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**

PKIX (Public-‐Key Infrastructure -‐ X.509)

hcps://en.wikipedia.org/wiki/PKCS hcps://datatracker.ie4.org/wg/pkix/

How is used: •  Create CA, RA, e-‐DNI, SSL, Digital Dignature of

documents, Sign SoNware, …

Other standards related: •  RSA PKCS (Public Key Cryptography Standards)

1.  eID DSS •  Belgium Federal ICT Department (FedICT) •  hcps://code.google.com/p/eid-‐dss

6. FOSS Crypto products

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.

2.  Digital Signature Service •  European Comission – Interoperability SoluBons for European Public

AdministraBons (ISA) •  hcp://joinup.ec.europa.eu/soNware/sd-‐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

3.  SignServer: •  hcp://www.signserver.org


•  Is an applicaBon framework performing cryptographic operaBons for other applicaBons. •  It's intended to be used in environments where keys are supposed to be protected in hardware but it isn't 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.

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://www.ejbca.org


Features: •  hcp://www.ejbca.org/features.html •  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).

5.  The Sirius Signing Server •  hcp://sirius-‐sign.sourceforge.net •  hcps://sirius.atlassian.net


•  Sirius Server is a signing and verificaBon soNware suite with it's 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

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://www.openoces.org/opensign/index.html


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

7.  CryptoApplet •  Is a Java applet for advanced digital signature creaBon. •  hcp://proyectosBc.uji.es/pr/cryptoapplet


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 Sun's Java Virtual Machine (version 1.5 o higher) installed.

8.  Open eSignForms •  Is the first free and open source, web contracBng soNware

applicaBon (on-‐premise) and SaaS (hosted). •  hcp://www.openoces.org/opensign/index.html


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.

9.  OpenXAdES •  OpenXAdES is technology that enables people to work with

legally binding digital signatures. •  hcp://openxades.org


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.

10.  Open-‐VA •  hcp://sourceforge.net/projects/open-‐va


Trusted Third Party (TTP) and Cryptography Services

Hardware Security Module (HSM)

Authentication Authorization SSO Identity Mngmt

Enterprise Service Bus

7. Architecture for Crypto SOA

Time Stamp Creator

Digital Signature Creator

Certification Authority (PKI)

Existing and Legacy Apps

Srvc1 Srvc3 Srvc2 Srvc4 Srvc6 Srvc5 Srvc7 Srvc9 Srvc8 Srvc10

CMS ERP

CRM BPM

BI

Web Portal Mobile B2B / B2C

PDF Signature Creator

Digital Signature Validator

Secure Archiving

JMS IDOC FTP JMS REST SOAP SRV3 SRV4 SRV5 SRV6 SRV1 SRV2

ADAPTERS

CRYPTO WS

Activity Monitoring

-Time Server -OCSP

Client/Applet Liferay/DocLib WSO2 ESB/Proxy TTP/Validator

1

3

4 5

8. Use Case#1: Signing in the client side

2

1

2

3

4

5

User want to sign a document with his private and public key stored in his Smart Card.

CA, TSA, OCSP, …

Document Library

ESB Users

The Applet creates hash and when are creaBng signature, it calls to TTP for validaBng keys/cerBficates (OCSP, Time Stamp, CRL, …).

Liferay is a place to store document, signed documents, sigantures, etc.

WSO2 ESB is just a WS Proxy.

TTP is the validator of idenBBes (keys/cerBficates), status of credenBals (cerBficate is or not revoked?, OCSP, CRL, …). TTP gives us a trust Bme (Time Stamping).

Client Liferay/DocLib WSO2 ESB/Proxy TTP/Validator

4

6

9. Use Case#2: Signing in the server side

1

CA, TSA, OCSP, …

Document Library ESB

Users

2 3

5

1

2

3

4

5

User wants document to be signed. User sends document to be signed.

Liferay receives the document and save it, then It calls to WSO2 ESB for creaBng signature.

WSO2 receives signing request and It prepares the creaBon of signature (get Bme stamp, validate keys/cerBficate, …)

TTP sends informaBon on status of validaBon to WSO2 ESB.

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.

Client Liferay/DocLib WSO2 ESB/Proxy TTP/Validator

4

5

10. Use Case#3: Time Stamping

1

CA, TSA, OCSP, …

Document Library

ESB

Users

2 1

2

3

4

5

The user wants to store a document in the repository

Liferay receives the document and save it, then It calls to WSO2 ESB for creaBng Bme stamp.

WSO2 receives Bme stamping request and re-‐send to TTP. In this case WSO2 ESB is just a Proxy, but could replace TTP.

TTP sends Bme stamping (signature) to Liferay. WSO2 ESB knows if request was responded.

Liferay receives response message (Bme stamping) and saves it inside.

Atomic Clock

DSS.wsdl

TS Req

uest

TS Respo

nse

11. Use Case#3: ValidaBon Time Stamp

12. Business Cases

Processes Workflow

Content Documents

Archive

¤  E-‐Invoice ¤  E-‐Notary

¤  Cer-fied Digi-za-on of Documents

¤  Long Term Archiving

¤  Any process looking for non-‐repudia-on

¤  DRM

¤  E-‐Burofax

¤  Records Management

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

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.

14. Conclusions

Thank you

IT & FOSS Consultant SOA, BPM, ECM, Portal and Security.

You can reach me on:

holisticsecurity.worpress.com

@chilcano

www.linkedin.com/in/rcarhuatocto

roger [AT] konosys.es

+34 629292125

Roger CARHUATOCTO

WSO2Con 2013 - WSO2 as a Crypto Platform

Technology

Transcript of WSO2Con 2013 - WSO2 as a Crypto Platform