A Crypto SOA Platform with WSO2

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

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

14. 4.
OrganizaBons
for
XML
Standards
WS-­‐*
World
Wide
Web
XML
Consor-um
Internet
Engineering
PKIX
Task
Force

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. 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-­‐open.org/commicees/
(ID-­‐FF).
security
• Shibboleth
• XACML
• WS-­‐Security

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-­‐open.org/commicees/ Other
standards
related:
xacml
• SAML

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-­‐open.org/commicees/
• XML-­‐Enc
wss
• WS-­‐SecureConversaBon

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://www.w3.org/Signature/
• SOAP
• SAML
• XML-­‐Enc

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://www.w3.org/TR/XAdES/
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. 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://www.w3.org/EncrypBon/2001/
contains
or
idenBfies
the
cipher
data.
• TLS/SSL
• PGP

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-­‐open.org/commicees/ • 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. 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. 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://en.wikipedia.org/wiki/PKCS
cerBficates
in
a
central
repository,
and
revokes
hcps://datatracker.ie4.org/wg/pkix/
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. 6.
FOSS
Crypto
products
1. eID
DSS
• Belgium
Federal
ICT
Department
(FedICT)
• hcps://code.google.com/p/eid-­‐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. 6.
FOSS
Crypto
products
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

27. 6.
FOSS
Crypto
products
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.

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://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).

29. 6.
FOSS
Crypto
products
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

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://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

31. 6.
FOSS
Crypto
products
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.

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://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.

33. 6.
FOSS
Crypto
products
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.

34. 6.
FOSS
Crypto
products
10. Open-­‐VA
• hcp://sourceforge.net/projects/open-­‐va

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 BPM
Certification -Time Server Hardware Digital Time PDF Secure Digital
Authority -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. 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. 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. 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. DSS.wsdl

40. TS
Request

41. TS
Response

42. 11.
Use
Case#3:
ValidaBon
Time
Stamp

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. 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. 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. Thank
you

47. Roger
CARHUATOCTO
IT & FOSS Consultant
SOA, BPM, ECM, Portal and Security.
You can reach me on:
holisticsecurity.worpress.com roger [AT] konosys.es
+34 629292125
@chilcano
www.linkedin.com/in/rcarhuatocto