wso2con 2013 - wso2 as a crypto platform
Post on 06-May-2015
1.321 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
Canal of CommunicaBon Web Service Business
ApplicaBons
Trusted Third Party
Security Context
Client Requester
Canal of CommunicaBon Web Service Business
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
6. FOSS Crypto products
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
6. FOSS Crypto products
• 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
6. FOSS Crypto products
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
6. FOSS Crypto products
• 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
6. FOSS Crypto products
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
6. FOSS Crypto products
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
6. FOSS Crypto products
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
6. FOSS Crypto products
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
6. FOSS Crypto products
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
top related