Securities in Domestic and Cross-border Data exchange Securities in Domestic and

Cross-border Data exchange

2012. 52012. 5

Security Issue

• paperless trade process need electronic data exchanges.

• cross domain, cross border data exchanges need secure, stan-dard, technology-neutral interface

• data exchanges are performed with the most economic and ef-fective means via the Internet, anytime and anywhere.

• In standard, internet environment, security issue become more and more important

Security Issue

Security goal (triad CIA)

Confidentiality : Who is authorized.. ?Integrity : Is the data good.. ?Availability : Can access data whenever need it.. ?

Security goal

Confidentiality Integrity Availability

Three item should be balanced.

Security Issue

Confidentiality• Keeping information secret from unauthorized access.• It is probably the most common aspect of information security: we

need to protect confidential information. • An organization needs to guard against those malicious actions

that endanger the confidentiality of its information.

Integrity• Changes should be done only by authorized users and through

authorized mechanisms.• Includes data integrity (content) and origin integrity (source of

data also called authentication)

Availability

• The information created and stored by an organization needs to be available to authorized users and applications.

Security Issue

Attack- Threat to security goal (confidentiality, Integrity, availability)- Any action (active or passive) that compromises the security of information.

Security Attacks`

Snooping

Trafficanalysis

Modification

spoofing

Replaying

Repudiation

Denial ofService

Threatconfidentiality Threat

Integrity

Threatavailability

Security Issue

Attack

threat method description

confidentialitysnooping intercepting information

traffic analysis observe pattern of message

integrity

modification alteration of information

spoofing

masquerades as another by falsifying data and thereby gaining an illegitimate advan-tage.

replaying capture message and later replay message

repudiationthe act of refusing receiving or sending mes-

sage

availability denial of serviceattempt to make a computer or network re-source unavailable to its intended user

Security Issue

Network security issue – (1)

• AuthenticationBoth sender and receiver need to verify the identity of the other party in a communication: are you really who you claim to be?

• Authorization prevention of the unauthorized use of a resource. does a party with a verified identity have permission to ac-cess (r/w/x/…) information? Gets into access control policies.

• Confidentiality protection of data from unauthorized disclosure. en-crypt message so only sender and receiver can under-stand it

Security Issue

Network security issue – (2)

• Integrity the assurance that data received are the same as send by an authorized entity. during a communication, can both sender and receiver detect whether a message has been altered?

• Non-Repudiation provides protection against denial by one of the entities involved in a communication of having participated in all or part of the communication.

• AvailabilityGuaranteeing access to legitimate users. Prevention of Denial-of-Service (DOS) attacks.

Security Issue

Cryptography

• The actual implementation of security goals needs some help from mathematics

• Cryptography is a framework of methodologies used to en-sure the CIA triad for our information

• The need for cryptographic techs was as old as the need to keep the critical info secure, safe and authentic.

Cryptography

Symmetric Key Encryption

• Both parties share the same key for en- and decryption• To provide privacy, this key needs to be kept secret• All classical encryption algorithms are private

key(symmetric key)• Faster than asymmetric, hard to break with large key (but

hard to distribute keys, too many keys required)• Used for long messages• Hard to authenticate or provide non-repudiation

Cryptography

Block ciphers

• Blocks of bits (e.g. 64, 128) encrypted at a time

• Examples of several algorithms:– Data Encryption Standard (DES) – 64 bit block, 56 key – Triple DES– Advanced Encryption Standard (AES) or Rijndael– IDEA (Internal Data Encryption Algorithm) – Europe– FEAL (Fast Data Encryption Algorithm) - Japan– Seed, Aria - Korea – GOST - Russia

• CAST, Blowfish, Skipjack, many more… (c.f. Schneier)

Cryptography

DES (Data encryption Standard)

• Designed by IBM• Published in 1977 by NIST (FIPS-46)• Adopted also by ISO an standard of ANSI• Used by many private enterprise, bank • Susceptible to Brute-Force (try all 256 keys)

– 1998: machine Deep Crack breaks it in hours– Subsequently been able to break even faster

Cryptography

DES (Data encryption Standard)

• Input: 64-bit plaintext(block), 56-bit key (64 w/ parity)• Output: 64-bit ciphertext

Cryptography

Triple DES

• Made part of DES in 1999• Uses 3 keys and 3 DES executions

– using 3 keys 3DES has an effective key length of 168 bits (3*56)

– follows encrypt-decrypt-encrypt (EDE)– 3x slower than DES

• FIPS algorithm of choice• using DES are encouraged to convert to 3DES

Cryptography

AES (Advanced Encryption Standard - Ri-jndael)

• Designed by Rijmen-Daemen in Belgium

• US National Institute of Standards and Technology (NIST) in 2001 in response to the shortcoming of DES

• Selected by NIST from 15 competitors after three years of confer-ences vetting proposals

• Selection Criteria: – Security, Cost (Speed/Memory)– Implementation Considerations (Hardware/Software)

• Key size & Block size: 128, 192, or 256 bits (much larger than DES)

• Rely on algorithmic properties for security, not obscurity

Cryptography

AES (Advanced Encryption Standard - Ri-jndael)

• Key size & Block size: 128, 192, or 256 bits (much larger than DES)

Cryptography

Stream Cipher

• Much faster than block ciphers and used in hardware and network cipher

• Encrypts one byte of plaintext at a time

• Keystream: infinite sequence (never reused) of random bits used as key

• Approximates theoretical scheme: one-time pad, trying to make it practical with finite keys

Cryptography

RC4

• The most widely used software Stream cipher and is used in popular protocols such as SSL and WEP (to secure wire-less networks).

• 10x faster than DES

• Fixed-size key “seed” to generate infinite stream

• State Table S that changes to create stream

• Ex: 256-bit key used to seed table (fill it)

Cryptography

Asymmetric Key Encryption

Cryptography

• Unlike symmetric-key cryptography, there are distinc-tive keys(private, public key) in asymmetric-key cryp-tography

• Encryption performed with one asymmetric key de-crypted only with corresponding key

Asymmetric Key Encryption

• Diffie and Hellman in 1976 invented asymmetric public key cryptography (revolutionary!) - Sender’s key differs from receiver’s key- Simplifies key distribution – just protect Private key- Useful for authentication as well as encryption

• Asymmetric key encryption are incredibly complex, Asym-metric key encryption is up to 1000 times slower than symmetric key encryption.

• Examples of several algorithms:– RSA– ECC (Elliptic Curve Cryptography)

Cryptography

RSA

• Invented by Rivest/Shamir/Adelman (1978) – First asymmetric encryption algorithm– Most widely known public key cryptosystem

• Used in many protocols (e.g.., SSL, PGP, …)

• Number theoretic algorithm: security based on difficulty of factoring large prime numbers

• 1024, 2048, 4096-bit keys common

Cryptography

ECC (Elliptical Curve Crytography)

• ECC was invented by Neil Koblitz and Victor Miller in 1985, eight years after the RSA algorithm

• ECC has been studied extensively for 20+ years and is well recognized and accepted world-wide for its strong number-theoretic foundation.

• ECC has been standardized internationally by ISO and the IETF and within the US by ANSI and NIST

• Elliptical Curve Cryptography is much stronger per bit than RSA and is less computationally intensive

Cryptography

Hybrid Encryption (Symmetric + Asymmet-ric)

• Use symmetric algorithm in encrypting original message

• Use asymmetric algorithm for protecting symmetric encryp-tion keysfor protecting key distribution

• Just don’t let the secret key travel unless it was asymmetri-cally encrypted

• Uses best advantages of each approach

• It’s widely used in SSL , Enveloped-Data and many com-mercial software

Cryptography

Hybrid Encryption (Symmetric + Asymmet-ric)

Generate a random symmetric encryption

key(CEK)

Encrypted CEK with recipient public Key (1)

Message (en-crypted by

CEK)

Decrypt CEK with recipient Private Key(1)

Message (de-crypted by

CEK)

Sender Receiver (1)

Cryptography

• Use symmetric key in message encryption/decryption• Use asymmetric key in key distribution (key encryption/

decryption)

Encrypted CEK with recipient public Key (2)

Message (de-crypted by

CEK)

Receiver (2)

Decrypt CEK with recipient Private Key(2)

Message digest

• A hash function H is a transformation that takes an input m and returns a fixed-size string, which is called the hash value h (that is, h = H(m)).

• A hash function H is said to be one-way because it is hard to invert, where “hard to invert'' means that given a hash value h, it is computationally infeasible to find some input x such that H(x) = h.

• Examples of well known hash functions are MD-x and SHA-x

Cryptography

Message digest algorithm

• MD5 (Message Digest Algorithm 5) - Produces a 128 bits hash value - In 2004, flaws were discovered and its usage was discour-aged.

• SHA (Secure Hash Algorithm) - Ranges from 160 bits to 512 bits, depending on the cho-sen flavor. - One of the most secure algorithms.

• CRC-32 (Cyclic Redundancy Check) - Used for data integrity in networks - Not suitable for security (very poor randomness).

Cryptography

Algorithm Strength

Crypto-graphic strength

Symmetric(Key length)

Asymmetric Hashing/MACs (hash value length)

Weak DES 40-bitRC4 40-bit

RSA 256-bit

medium DES 56-bitCAST 64-bit

RSA 512-bitD-H 512-bitDSA 512-bit

ANSI X9.9 MAC 32-bit

strong Triple DES 112-bitAES 128-bitIDEA 128-bitRC4 128-bit

RSA 1024-bitD-H 1024-bitDSA 1024-bit

MD5 128-bit SHA-1 160-bit

Very strong AES 192-bitAES 256-bit

RSA 2048-bitECC 300-bit

SHA224,SHA-256SHA-384SHA-512

NotRecommend

Recommend

Cryptography

Algorithm war-entee(year)

Strength(bit)

Asymmetric algorithm

Hash functionRSA

KCDSA

Public key Private key

- 2012 80 1024 1024 160 SHA-1

2013 – 2030 112 2048 2048 224 SHA-256

2030 - 128 3072 3072 256 SHA-256

192 7680 7680 384 SHA-3

256 15360 15360 512 SHA-512

• NIST recommends phasing out 80-bit crypto by 2010

• Agencies need to initiate policies and architectures now for eventual migration to stronger cryptography

• NIST recommends phasing out 112-bit crypto by 2030

NIST Recommendation

Cryptography

Digital Signature

• Digital signature can provide authentication, integrity, and nonrepudiation for a message.

• Digital signature does not provide privacy(confidentiality). If there is a need for privacy, another layer of encryption/de-cryption must be applied.

• There is still a problem linked to the “Real Identity” of the Signer.

• So the need to PKI (public key infrastructure)

Digital Signa-ture

sign and verify

Message

Hash

Digest

Encryption

Signature

Private Key

Message

Hash

Actual Digest

Decryption

Expected Di-gest

PublicKey

Sign processverify

process

Compare

Real signer’s key

PublicKey

(certificate)

Cert vali-dation

Digital Signa-ture

transfer

Digital Certificate

• A Digital Certificate is a binding between an entity’s public Key and one or more attributes relating its identity

• The entity can be a Person, an Hardware Component, a Service, etc.

• A Digital Certificate is issued (and signed) by someone

• A self-signed certificate usually is not very trustworthy (Is-suer = subject)

• X.509 – “the certificate standard” today– v.1 (1988) – not extendable– v.2 – not much better– v.3 (1997) is much better – optional extensions

Today, X.509=v.3– Many other standards extend X.509

Digital Certifi-cate

X.509 v3 Certificate

Digital Certifi-cate

PKI (public Key Infrastructure)

“A public-key infrastructure(PKI) is a set of hardware, software, people, policies, and procedures needed to cre-ate, manage, distribute, use, store, and revoke Digital Certificate”

PKI

PKI Component

• Certificate Authority (CA)- Issuer/Signer of the certificate- Manage for Lifecycle of Certificate (create, store, revoke)

• Registration Authority (RA)- Also called LRA – Local RA- Support Identification of entity- Interface to CA

• Certificate Distribution System (CDS)- Digital certificates issued by CAs need to be made available to other

network users. - A CDS is normally implemented as an ITU-T X.500 directory database or

a Lightweight Directory Access Protocol (LDAP)- stores certificates and maintains a list of revoked certificates

• PKI applicationsApplications that use the PKI technology

PKI

Certificate Validation

• Integrity: signature is valid

• Signed by a trusted CA– or certification path is rooted in a trusted CA

• Certificate is valid now: – We are between Not Valid Before and Not Valid After

time points in the certificate

• Not Revoked (by CRL check or OCSP)

• Use is consistent with the policy (CPS , CP)

PKI

Certificate Polices

• Certificate Policy (CP)- A document that sets out the rights, duties and obliga-tions of each party in a Public Key Infrastructure

- “high level what is supported” document- usually has legal effect- A CP is usually publicly exposed by CAs, for example on a Web Site (VeriSign, etc.)

• Certification Practice Statement (CPS)- A document that sets out what happens in practice to

support the policy statements made in the CP in a PKI- “detailed, comprehensive, technical how policy is sup-ported” document

PKI

PKI Trust Model - CA Hierarchy

• The root CA’s certificate is self signed and each sub-CA is signed by its par-ent CA.

• Each CA may also issue CRLs. In par-ticular the lowest level CAs issue CRLs frequently.

• End entities need to “find” a certific-ate path to a CA that they trust.

Root CA

CA _A CA _B

E_1 E_2 E_3 E_4

PKI

PKI Trust Model – Cross-Certificate (Mesh)

CA _A

CA _B

CA _C

CA _D

• CAs deal with each other as peers and choose whether or not to trust each other.

• the CAs issue cross-certificates to each other and need policy mapping and agreement

• A user can then trace a certificate from an unknown CA back to a local trusted CA

• achieving interoperability through a mesh of certifications is technically and logistically challenging

• It’s not an ideal approach to establish-ing a broad, multi-national PKI

• cross certification is most suited where two or three related CAs

PKI

PKI Trust Model – Bridge CA

CA _A

CA _B

CA _C

CA _D

Bridge CA

• bridge CA model is based on a central (bridging) CA which cross-certifies with each CA.

• combines aspects of both the root model and the cross-certification model

• bridge model allows for PKIs built using different models to be joined together in a single, interoperable network

• bridge must set certain minimum standards for CAs to participate.

Cross-cer-tificate

PKI

PKI Trust Model – Cross-recognition

CA _A

Coordinating au-thority

CA _CCA _B

Agreement

• Cross recognition is where an indi-vidual CA or an entire PKI domain agrees to recognize another CA or domain

• requires close co-operation among either the CAs at an administrative level or accreditation agencies

(and governments) at a higher level

• trust model that is being pursued by the Asia Pacific Economic Co-operation

(APEC) Telecommunications (TEL) Working Group

PKI

PKI Trust Model – Certificate Trust List model

CA _A

Publishing au-thority

CA _CCA _B

Certificate Trust List

• The Certificate Trust List (CTL) is a list of CAs’ certificates from a trusted authority

• Trust lists have also given rise to the ‘browser’ model - the most widespread interoperable PKI by virtue of web browser applications (such as Internet Explorer, Net-scape or Firefox)

PKI

Features Hierarchy Cross-cert(Mesh) Bridge

Trust anchor Root CA Local CA Bridge CA

Certificate path construction Simple Complex Simple

Verification process Simple Complex Complex

Expansibility Good Good Good

Failure Point - Root CA- Policy Pressure No failure point

- Bridge CA- Policy Pressure

Support for common application SW

Good Weak Weak

CA Trust model comparison

PKI

PKI Trust Model in Korea

ForeignGovernment

Ministry of public Administration and secu-rity

National Root CA(KISA)

Government Root CA

(GCMA)

Ac-cred-ite CA

Ac-cred-ite CA

Ac-cred-ite CA

Mutual Recogni-

tion

ForeignCA Cross

Certifica-tion

PKI

CTL

User

User

Ac-cred-ite CA

NPKI

Ac-cred-ite CA

GPKI

User

User

Ac-cred-ite CA

User

User

User

User

NPKI vs. PKI

Category National PKI PKI system

Customer Accredited CA, Root CA PKI products

Base Law (Electronic transactionAct and decrees)

Domestic/InternationalStandards

Scope ofEvaluation

Wide(System, Policy, Operation)

Narrow(Only System)

Compensation Easy to get compensated N/A

Interoperability Guaranteed by Law Impossible

Application All for public (E-Government,E-Procurement, E-Commerce,E-Banking, E-Tax, etc)

Only for the limited area(Private Service)

Level oftechnology andsecurity

Very secure(proved technology + law)

Secure(proved technology)

Burden of Proof Accredited CA User

Usage Infrastructure System (Software)

PKI

CMS (cryptographic message syntax)

• cryptographic Message Syntax describes an encapsula-tion syntax for data protection. It supports digital signa-tures, encryption and message authentication codes

• there are six content types defined in the RFC 3852, data, signed-data, enveloped-data, digested-data, en-crypted-data, and authenticated-data

• CMS is derived from PKCS #7 version 1.5 (it was origi-nally published as an RSA Laboratories Technical Note in November 1993)

CMS

General Syntax (ASN.1 structure)

ContentInfo ::= SEQUENCE { contentType ContentType, content [0] EXPLICIT ANY DEFINED BY content-Type }

ContentType ::= OBJECT IDENTIFIER

CMS

data OBJECT IDENTIFIER

SignedData iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2

EnvelopedData iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3

DigestedData iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5

EncryptedData iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6

AuthData iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2

Content Type

Content

Signed-data

• used to cryptographically sign the content, can have more then one signer

• Data can be encapsulated in signed-data or can be de-tached.

• Any number of signers in parallel can sign any type of con-tent.

• The typical application of the signed-data represents one signer's digital signature on content of the data content type.

• Another typical application disseminates certificates and certificate revocation lists (CRLs).

CMS

Signed-data

Version

(Set of) Digest Algorithms

EncapContentInfo

Set of certificates

Set of CRLs

Signer Info

Version

Signer ID (issuer and ser. no.)

Digest Algorithm

Authenticated Attributes

Digest Encryption Alg.

Encrypted digest (signature)

Content type

Content

CMS

Enveloped-data

• The enveloped-data content type consists of an encrypted content of any type

• encrypted content-encryption keys for one or more recipi-ents.

• The combination of the encrypted content and one en-crypted content-encryption key for a recipient is a "digital envelope" for that recipient.

• Any type of content can be enveloped for an arbitrary number of recipients using any of the three key manage-ment techniques for each recipient.

CMS

Enveloped-data

Version

Encrypted Content Info

Recipient Info

Version

Recipient ID (issuer and s.no.)

Key Encryption Algorithm

Encrypted Key

Content Encryption Alg.

Content type

Encrypted Content

Originator Info

CMS

S/MIME

• security enhancement to MIME email• original Internet RFC822 email was text only• MIME provided support for varying content types and multi-

part messages• Base on CMS (signature, encryption)

• have S/MIME support in many mail agents• e.g MS Outlook, Mozilla, Mac Mail etc

• S/MIME is not restricted to mail; it can be used with any transport mechanism that transports MIME data, such as HTTP.

SSL (Secure socket Layer)

• transport layer security service• originally developed by Netscape (1993)• version 3 designed with public input• subsequently became Internet standard known as TLS

(Transport Layer Security)• SSLv3.0 -> TLS v1.0 (SSLv3.1 backward compatible with

SSLv3.0)• The SSL Security protocol provides confidentiality(data en-

cryption), authentication(server and optional client), in-tegrity(message) for a TCP/IP connection.

SSL

SSL Layer

TCP/IP Layer Protocol

Application Layer HTTP, IMAP, NNTP, Tel-net, FTP, etc.

Secure Sockets Layer SSL

Transport Layer TCP

Internet Layer IP

SSL

SSL Protocol

• Handshake protocolthe server and client to authenticate each other and to negotiate an encryption and MAC algorithm and cryptographic keys to be used to protect data sent in an SSL record.

• Change Cipher spec protocolalert to a change in communication variables

• Alert protocolused to convey SSL-related alerts to the peer entity.

• Record protocoltakes an application message to be transmitted, fragments the data into blocks, compresses the data (optionally), applies a MAC, encrypts, adds a header and transmits the resulting unit.

SSL

SSL Handshake Protocol – (1)

1. Client hello(C) - The client sends the server information includ-ing the highest version of SSL it supports and a list of the cipher suites it supports.

2. Server hello(S) - The server chooses the highest version of SSL and the best cipher suite that both the client and server support and sends this information to the client.

3. Certificate(S) - If server authentication is required then the server sends the client a certificate or a certificate chain.

4. Certificate request(S) - If the server needs to authenticate the client, it sends the client a certificate request.

5. Server key exchange(S) - The server sends the client a server key exchange message when the public key information sent in 3) above is not sufficient for key exchange.

6. Server hello done(S) - The server tells the client it is finished with its initial negotiation messages.

SSL

SSL Handshake protocol – (2)

7. Certificate(C) - If the server requests a certificate from the client in Message 4, the client sends its certificate chain, like the server did in Message 3.

8. Client key exchange(C) - The client generates information used to create a key to use for symmetric encryption. For RSA, the client then encrypts this key information with the server's public key and sends it to the server.

9. Certificate verify(C) – If the server is authenticating the client, the client sends a random number that it digitally signs. When the server decrypts number with the client's public key, the server authenticates the client.

10. Change cipher spec(C) - The client tells the server to change to encrypted mode.

SSL

SSL Handshake detail – (3)

11. Finished(C) - The client sends the server a hash of the hand-shake messages.

12. Change cipher spec(S) - The server tells the client to change to encrypted mode.

13. Finished(S) - The server sends the client a hash of the hand-shake messages.

• Encrypted data - The client and the server communicate using the symmetric encryption algorithm and the cryptographic hash function negotiated in Messages 1 and 2, using the secret key that the client sent to the server in Message 8. (SSL Record Pro-tocol)

SSL

SSL Record Protocol

SSL

SSL coverage

• Now a day. SSL implements is embedded in WAS, JDK and have interoperability

• For simple case - Good enough..

• But for B2B Infrastructure - SSL only supports data in transit, not in storage - SSL does not support multi-party transactions - SSL does not support non-Repudiation

SSL

SSL Attack

SSL

Web Browser orMessaging Server

Web Server orMessaging

Server

Hacker(Man-in-the-

Middle)Or Bad AP

NoSSLOr SSL

SSL

SSL

• SSL communications can be intercepted.• SSLStrip, a man-in-the-middle proxy that, in prin-

ciple, changes all the user's https requests into http requests

• Strict SSL Authentication is need

SSL Client authentication

browser Webserver

e.g) internetexplore

ClientAuth = false

check server certificate by

truststore

Messag-ing

Client

Messagingserver

ClientAuth = true

check server certificate by

Truststoreor

PathValidation

check client certificate by

Truststoreor

PathValidation

SSL

XML Security

• XML is a structured format and provide modularity and ex-pandability so widely used in B2B, EAI, and e-Commerce standard.

• XML is basis for distributed systems protocols.

• Allows for secure storage of documents,

• Leverages existing technologies

XML Security

XML security - standard

• Canonical XML/Exclusive XML Canonicalizationhttp://www.w3.org/TR/xml-c14n/

http://www.w3.org/TR/xml-exc-c14n/

• XML Signature (XMLDSig)http://www.w3.org/TR/xmldsig-core/

• XML Encryption (XMLEnc)http://www.w3.org/TR/xmlenc-core/

• XML Key Management (XKMS)http://www.w3.org/TR/xkms2/

XML Security

XML Signature (XMLDSig)

• Made by W3C and IETF working group

• XML Signatures are digital signatures used in XML transac-tions

• May be used to sign only a portion of an XML document. The document might have a long history with different parts holding different signatures

XML Security

XML signature structure

XML Security

XML Signature

• Enveloping Signature– Data lives within the XML Signature

structure– Good for signing data being packaged

within an XML payload

• Enveloped Signature– Data lives outside of and contains the

XML Signature structure– Good for signing portions or all of an

XML document

• Detached Signature– Data lives outside and DOES NOT con-

tain the XML Signature structure– Data may reside at a remote location

addressable by URI

Signa-ture

Signa-ture

Target

Signa-ture

TargetSigna-ture

SignatureTarget

Signature

URIRefer-ence

XML Security

Signature process

<Reference>..

</Reference>

<Reference>..

</Reference>

<SignatureMethod> <CanonicalizationMethod>

<SignedInfo>

Canonicalizer

SignatureKey

<Signa-tureValue>

……

</Signa-tureValue>

<Signature>

<SignedInfo>

..

</SignedInfo>

<SignatureValue>

</Signa-tureValue>

</Signature>

XML Security

Reference

• target content for sign• <ds:Reference URI="">• All references are identified by a URI

URI type description

URI="“Identifies the node-set (minus any comment nodes) of the XML resource containing the signature

URI="#chapter1“Identifies a node-set containing the element with ID attribute value 'chapter1' of the XML resource con-taining the signature.

URI=“http://example.com/bar.xml”

Identifies the element with ID attribute value 'chap-ter1' of the external XML resource

URI=“http://example.com/bar.xml#chapter1”

Identifies the element with ID attribute value 'chap-ter1' of the external XML resource 'http://example.-com/bar.xml', provided as an octet stream

XML Security

Transform

• Transforms are an ordered list of operations applied to the document before signing

• This provides finely-grained application of signatures. Using transforms, you can isolate arbitrary content to sign, leaving the rest of the document open to change

• Might include canonicalization, Base 64, Xpath filtering, XSLT transforms– Applied to octet stream residing at a reference or to

the output of any previously applied transform

• User-defined transforms can also be applied

XML Security

Transform Algorithm

Transform 1

- Enveloped Signature http://www.w3.org/2000/09/xmld-

sig#enveloped-signature

- XPathhttp://www.w3.org/TR/1999/REC-

xpath-19991116

- XSLThttp://www.w3.org/TR/1999/REC-

xslt-19991116

Transform 2

Transform 3

ReferenceURI=“#body

”

TRANS A

Hash value

TRANS B

http://www.w3.org/TR/2001/REC-

xml-c14n-20010315

j6lwx3rvE-PO0vKtMup4N-

beVu8nk=

XML Security

Canonicalize XML (C14N)

• Purpose– The purpose of canonical XML is to define a standard

format of an XML document– XML can be different form accroding to XML Processor

or editor however logical XML content is same. – A set of operations performed on the XML contents

prior to signature application or verification• For example: hide irrelevant character-level modifi-

cations of the XML document

• Two Different Canonicalization– Inclusive Canonicalization– Exclusive Canonicalization

XML Security

Canonicalize XML (C14N)

• XML declaration and DTD are removed• Encode document in UTF-8• Change each line break to a single linefeed• Empty elements are converted to start-end tag pairs• Whitespace outside of the document element and within

start and end tags is normalized• Attribute value delimiters are set to double quotes• Superfluous namespace declarations are removed from

each element• Lexicographic order is imposed on the namespace declara-

tions and attributes of each element

XML Security

Canonical example

<!DOCTYPE doc [<!ATTLIST e9 attr CDATA "default">]>< doc> <e1 /> <e2 ></e2> <e3 name = "elem3" id="elem3" /> <e4 name="elem4" id="elem4" ></e4> <e5 a:attr="out" b:attr="sorted" attr2="all" attr="I'm" xmlns:b="http://www.ietf.org" xmlns:a="http://www.w3.org" xmlns="http://example.org"/> <e6 xmlns="" xmlns:a="http://www.w3.org"> <e7 xmlns="http://www.ietf.org"> <e8 xmlns="" xmlns:a="http://www.w3.org"> <e9 xmlns="" xmlns:a="http://www.ietf.org"/> </e8> </e7> </e6>< /doc>

<doc> <e1></e1> <e2></e2> <e3 id="elem3" name="elem3"></e3> <e4 id="elem4" name="elem4"></e4> <e5 xmlns="http://example.org" xmlns:a="http://www.w3.org" xmlns:b="http://www.ietf.org" attr="I'm" attr2="all" b:attr="sorted" a:attr="out"></e5> <e6 xmlns:a="http://www.w3.org"> <e7 xmlns="http://www.ietf.org"> <e8 xmlns=""> <e9 xmlns:a="http://www.ietf.org" atr="default"></e9> </e8> </e7> </e6> < /doc>

XML Security

Inclusive vs. Exclusive Canonical

• Inclusive Canonicalization– Leaving all namespace declarations within the signed sub-

tree in place– Including all namespace declarations that were specified

outside the signed subtree but also cover the signed subtree be included in the signed subtree’s root element

• Exclusive Canonicalization– “visibly utilized” namespace: the set of all namespaces that

have at least one element or attribute from that namespace occurring within the signed contents

– If a namespace is visibly utilized, its namespace declaration – regardless of its position within the signed subtree – is kept in place

– If that namespace happened to be declared outside of the signed subtree, its declaration is moved to the first element that visibly utilizes it

XML Security

• Inclusive canonicalization lead to severe interoperabil-ity issues

• Every addition of namespace declarations e.g. at a SOAP Envelope element lead to invalidation of every XML signature within that message

• WS-Security prefers the use of Exc-C14N• WS-I Basic Security Profile explicitly disallows the use

of Inc-C14N• Although Exc-C14N is more flexible, it has security risk

Inclusive vs. Exclusive Canonical

XML Security

KeyInfo

KeyInfo is an optional element that enables the recipient(s) to obtain the key needed to validate the signature

XML Security

<element name="KeyInfo" type="ds:KeyInfoType"/> <complexType name="KeyInfoType" mixed="true"> <choice maxOccurs="unbounded"> <element ref="ds:KeyName"/> <element ref="ds:KeyValue"/> <element ref="ds:RetrievalMethod"/> <element ref="ds:X509Data"/> <element ref="ds:PGPData"/> <element ref="ds:SPKIData"/> <element ref="ds:MgmtData"/> <any processContents="lax" namespace="##other"/> <!-- (1,1) elements from (0,unbounded) namespaces --> </choice> <attribute name="Id" type="ID" use="optional"/> </complexType>

XML encryption (XMLENC)

• Allow users to encrypt and decrypt data. both XML and non-XML content can be encrypted

• Encrypted data is maintained.• All information needed to decrypt a document is contained within

the document.• Session can be secured on the document level and shared

between multiple parties.• Sensitive data is easily interchanged between applications.

XML Security

XML encryption Structure

<enc:EncryptedData Id? Type? Mime-Type?>

<enc:EncryptionMethod Algorithm />?

<dsig:KeyInfo>? <enc:CipherData>

<enc:CipherValue>? <enc:CipherReference URI?>?

</enc:CipherData> <enc:EncryptionProperties>?</enc:EncryptedData>

• Encrypted elements are replaced by an <EncryptedData> element

• <EncryptedData> element contains:– A Type attribute – indicates the

type of the information en-crypted

– Information about the algorithm used for encryption

– An <EncryptedKey> element– <CipherData> A Reference to

the cipher, or the cipher itself• <EncryptedKey> - used for encrypt-

ing secret keys in symmetric key en-cryption

XML Security

XML encryption sample (Element/shared secret key)

<?xml version='1.0'?><PaymentInfo ><Name>John Smith</Name><CreditCard Limit='5,000' Currency='USD'> <Number>010-4357-5235</Number><Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PaymentInfo>

<?xml version='1.0'?><PaymentInfo > <Name>John Smith</Name> <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element' xmlns='http://www.w3.org/2001/04/xmlenc#'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData> </EncryptedData> </PaymentInfo>

Element encryption

origin

XML Security

XML encryption sample (Content/shared se-cret key)

<?xml version='1.0'?><PaymentInfo ><Name>John Smith</Name><CreditCard Limit='5,000' Currency='USD'> <Number>010-4357-5235</Number><Issuer>Example Bank</Issuer> <Expiration>04/02</Expiration> </CreditCard> </PaymentInfo>

<?xml version='1.0'?> <PaymentInfo > <Name>John Smith</Name> <CreditCard Limit='5,000' Currency='USD'> <Number> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2001/04/xmlenc#Content'><CipherData> <Cipher-Value>A23B45C56</CipherValue> </Ci-pherData> </EncryptedData> </Number> <Issuer>Example Bank</Issuer> <Expira-tion>04/02</Expiration> </CreditCard> </PaymentInfo>

Content encryption

origin

XML Security

XML encryption Structure

• Encrypted elements are replaced by an <EncryptedData> ele-ment

• <EncryptedData> element contains:– A Type attribute – indicates the type of the information en-

crypted– Information about the algorithm used for encryption– An <EncryptedKey> element– <CipherData> A Reference to the cipher, or the cipher itself

• <EncryptedKey> - used for encrypting secret keys in symmet-ric key encryption

XML Security

ebXML messaging (ebMS)

• ebXML is a modular suite of specifications that enables enter-prises of any size and in any geographical location to conduct business over the Internet.

• ebMS is a ebXML messaging Service component

• Establishment & Revision status - V1.0 : May 2001 - V2.0 : April 2002, OASIS standard, March 2004 ISO/TS 15000-2

- V3.0 : October 2007 OASIS standard

ebMS secu-rity

ebMS v2 message packaging

• The first MIME part, referred to as the Header Container, con-taining one SOAP 1.1 compliant message. This XML document is referred to as a SOAP Mes-sage for the remainder of this specification

• zero or more additional MIME parts, referred to as Payload Containers, containing applica-tion level payloads.

ebMS secu-rity

ebMS v3 message packaging

ebMS secu-rity

CPP – CPA configuration

PartyIDPartyID

PartyInfo

CollaborationProtocolProfile

CertificateCertificate

SecurityDetailsSecurityDetails

DeliveryChannelDeliveryChannel

TransportTransport

DocExchangeDocExchange

SimplePart

Packaging

CppIDCppID

Defines the Party's network commu-nication capabilities

Defines communication protocols (HTTP, SMTP and FTP) and Security in-formation

Specifies a logical address called Endpoint

Provides information that the Parties MUST agree on regarding exchange of documents between them. This in-formation includes the messaging service properties

ebMS secu-rity

ebMS v2 configuration

BusinessTransactionCharacteris-tics

setting

isConfidential nonetransient : secure transport protocol like SSLpersistent : digital envelope mechanism like S/MIMEtransient-and-persistent : digital envelope mechanism like S/MIME

isAuthenticated nonetransient : secure transport protocol like SSLpersistent : digital signature mechanismtransient-and-persistent

isTamperProof nonetransient : secure transport protocol like SSLpersistent : digital signature mechanismtransient-and-persistent

isNonRepudation FalseTrue : message must be digitally signed

ebMS secu-rity

ebMS v2 signature

• The only available technology that can be applied is XMLDSIG

• ebXML SOAP Header and Body to the ebXML Payload Con-tainer(s) or data elsewhere on the web that relate to the mes-sage

SOAP Envelope

Signature

Reference1

SOAP Body

SOAPHeader

Reference2

Payload_1

Reference3

Payload_2

ebMS secu-rity

ebMS v2 signature (2)

<Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"><XPath> not (ancestor-or-self::node()[@SOAP:actor="urn:oasis:names:tc:ebxml-msg:actor:nextMSH"] | ancestor-or-self::node()[@SOAP:actor="http://schemas.xmlsoap.org/soap/actor/next"] )</XPath></Transform>

<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>

Reference1 (URI="“) Reference2 (URI=""cid:// “)

• the Content-Id URI of the MIME body part of the payload object

• matching the Content-Location of the MIME body part of the payload object

• Or resolves to a payload object ex-ternal to the Message

ebMS secu-rity

ebMS v2 Mime Header Issue

ebMS secu-rity

Mime Part1

MimeHeader

SOAPEnvelope

Mime Part2

MimeHeader

Attachment

Mime Part3

MimeHeader

Attachment

Not pro-teced

Target for XMLDisg

MultiMimePart

• ebMS2 recommend not to use mime-header except mime parsing

Web-services standard stack

Composition/OrchestrationBusiness Process

Orchestration

PortalsManagement

XML, SOAP

XML Schema, WSDL, UDDI, SOAP with Attachments

HTTP, HTTPS,Others

Invocation

Description

Transports

Composable Service

ElementsTransactionalityWS-Security

Reliable Messaging

Endpoint Identification, Publish/SubscribeMessaging

AdditionalCapabilities

WS-Security

WS-Security

• soap message protection through message integrity, confidential-ity, and single message authentication

• The protocol was originally developed by IBM, Microsoft, and Verisign

• Provide a flexible set of mechanisms that can be used to con-struct a range of security protocols

• any ways of securing at message layer for WS is possible, WS-Se-curity is a standard way of securing WS.

• Provide message level and durable security

WS-Security

WS-Security structure

<wsse:Security> header block provides a mecha-nism for attaching secu-rity-related information targeted at a specific re-cipient in the form of a SOAP actor/role.

SOAP Envelope

Security

SecurityToken

Signature

SOAP Body

SOAPHeader

Encryption

WS-Security

Security Token

• Claim – A claim is a declaration made by an entity (e.g. name, identity, key, group, privilege, capability, etc).

• Security Token – A security token represents a collection (one or more) of claims.

• Signed Security Token – A signed security token is a security token that is asserted and cryptographically signed by a specific authority (e.g. an X.509 certificate or a Kerberos ticket , SAML).

WS-Security

UsernameToken Element

<wsse:UsernameToken wsu:Id=“…."> <wsse:Username> ... </wsse:Username> <wsse:Password Type="..."> ... </wsse:Password> <wsse:Nonce EncodingType="..."> ... </wsse:Nonce> <wsu:Created> ... </wsu:Created></wsse:UsernameToken>

@PasswordType description

#PasswordText (default) The actual password for the username, thepassword hash, or derived password or S/KEY.

#PasswordDigest The digest of the password

WS-Security

BinarySecurityToken Element

<wsse:BinarySecurityToken wsu:Id=...EncodingType=...ValueType=.../>

@EncodingType description

Base64Binary(default)

XML Schema base 64 encoding

WS-Security

@ValueType description

#X509v3 X509 v3 certificate

#Kerberosv5ST Kerberos v5 ticket

Token References

<wsse:SecurityTokenReference wsu:Id="..."> <wsse:Reference URI="..." ValueType="..."/></wsse:SecurityTokenReference>

WS-Security

Direct Reference

Key Identifier

<wsse:SecurityTokenReference> <wsse:KeyIdentifier wsu:Id="..." ValueType="..." EncodingType="..."> </wsse:KeyIdentifier></wsse:SecurityTokenReference>

SwA transform (SOAP Messages with Attach-ments)

• Attachment-Content-Signature-Transform (content only)The Attachment-Content-Signature-Transform indicates that only the content of a MIME part is referenced for signing. (http://docs.oasis-open.org/wss/oasis-wss-SwAProfile-1.1#Attachment-Con-tent)• Attachment-Complete-Signature-Transform(Mime Header + Con-

tent) This transform specifies that in addition to the content MIME headers are to be included when they are present(http://docs.oasis-open.org/wss/oasis-wss-SwAProfile-1.1#Attachment-Com-plete-Signature-Transform)

• Content-Description• Content-Disposition• Content-ID• Content-Location• Content-Type

Before calculate hash mime header, mime content must be canonicalized

WS-Security

SwA transform (SOAP Messages with Attach-ments)

WS-Security

• Attachment-Ciphertext-Transformonly the content of a MIME part is referenced, and contains the ciphertext re-lated to an XML EncryptedData element(http://docs.oasis-open.org/wss/oasis-wss-SwAProfile-1.1#Attachment-Cipher-text-Transform)

WS-Security sample

WS-Security

WS-Security risk

WS-Security

• Order of operationsReference validation before signature validation is ex-tremely susceptible to denial of service attacks in some scenarios

<ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ds:Transforms>

• Canonicalization Transform is expen-sive job.

WS-I (WS-* Interoperability)

WS-Security

• An open industry effort chartered to promote Web Ser-vices interoperability across platforms, applications and programming languages.

• A standards integrator to help Web services advance in a structured, coherent manner

• Approximately 150 member organizations

• It’s a standard of standard

• WS-I BSP(Basic Security Profile) address transport secu-rity, SOAP messaging security and other considerations.

WS-I BSP (v1.0)

WS-Security

item description

SSL/TLS TLS and SSL Ver-sions

A SENDER MUST NOT use SSL 2.0 as the underlying protocol for HTTP/S. A RECEIVER MUST NOT use SSL 2.0 as the underlying protocol for HTTP/S.

TLS and SSL Cipher-suites

mandatory TLS_RSA_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHASSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA

recom-mended

TLS_RSA_WITH_AES_128_CBC_SHA

discouraged ciphersuites that use 40 or 56 bit keys be avoidedMD5 algorithm

XML-Sig-nature

Type of signature

prohibited Enveloping Signatures

discouraged Enveloped Signatures

prefered Detached Signatures

Transform Allow follow-ing 6

• http://www.w3.org/2001/10/xml-exc-c14n#• http://www.w3.org/2002/06/xmldsig-filter2• http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-

message-security-1.0#STR-Transform• http://www.w3.org/2000/09/xmldsig#enveloped-signature http://

docs.oasis-open.org/wss/oasis-wss-SwAProfile-1.1#Attachment-Content-Signature-Transform

• http://docs.oasis-open.org/wss/oasis-wss-SwAProfile-1.1#Attachment-Complete-Signature-Transform

End to End Message level security

• Established when a message that traverses multiple applications (one or more SOAP intermediaries) within and between business entities, e.g. companies, divisions and business units, is secure over its full route through and between those business entities.

• ebMS or WS-Security provide end to end message level security

Initiator(re-

questor)

SOAPintermedi-

ary

Anyintermedi-

ary

WebServices

WS-Security

Firewall

Internet DMZ WAS DATA

Webserver

WebApplication

server

DB

SSL(transport)

Web-service se-curity

(message)

Transport vs. Message vs. content level se-curity

FileStorage

XML-DSIGor CMS

(content)

WS-Security

SAML (Security Assertion Markup Language)• A standard way of exchanging security & related data across heterogeneous, distributed systems crossing domain boundaries

• “Portable Trust” - a user, whose identity is established and verified in one domain, can invoke services in another do-main

- Cross-Domain Single Sign-On (SSO) - Federated Identity

• Web Services - provides a means by which security asser-tions about messages and service requesters can be ex-changed

(WS-Security - SAML Token Profile)

• Establishment & Revision status - SAML 1.0 was adopted as an OASIS standard in Nov 2002 - SAML 1.1 was ratified as an OASIS standard in Sep 2003 - SAML 2.0 became an OASIS standard in Mar 2005

SAML

SAML Component

• Assertions: Authentication, At-tribute and Authorization infor-mation

• Protocol: Request and Response elements for packaging asser-tions

• Bindings: How SAML Protocols map onto standard messaging or communication protocols (HTTP, SOAP)

• Profiles: How SAML protocols, bindings and assertions combine to support a defined use case

Profiles

Bindings

Protocol

Assertions

SAML

SAML assertions

An assertion is a package of information that supplies one or more statements made by a SAML authority

• Authentication The specified subject was authenticated by a particular means at aparticular time. This kind of statement is typically generated by a SAML authority called an identity provider

• Attribute The specified subject is associated with the supplied attributes

• Authorization The subject was granted or denied access to a specified re-source

SAML

SAML assertions structure

SAML

Issuer

Signature

Subject

Condition

Statement

Advice

• Issuer ID and issuance timestamp

• SubjectName plus the security domainOptional subject confirmation, e.g. public key

• ConditionsSAML clients must reject assertions con-taining unsupported conditions

• adviceE.g., to explain how the assertion was made

Statement

• Statement

SAML Protocol

SAML

A number of request/response protocols for communicating with SAML authority

• Request from a SAML authority one or more assertions • Request that an identity provider authenticate a principal and return the fresh corresponding assertion• Request that a name identifier be registered• Request that the use of an identifier be terminated• Retrieve a protocol message that has been requested by means of an artifact• Request a near-simultaneous logout of a collection of related sessions (“single logout”)• Request a name identifier mapping

Use Case

SAML

Idp(Identity provider)

SPs(Service provider)

Subjects(Principal)

Authenti-cation Au-

thority

AttributeAuthority

Assertionconsumer

Serviceresource

attribute

assertion

assertion

service

Use Case

SAML

Idp(Identity provider)

MessageClient

attribute

assertion

WS-Security with SAML assertion

response

MessageServer

request

Korea Tax invoice Relay system (v3)

According to the revised law of value-added tax in 2008, all of business companies should issue sales tax invoice in a standardized electronic tax invoice and it should be issued in standardized rule and be sent to the NTS by the 10th of the following month.”

NTS(National Tax

Service)

Businesscompany

ASP

Personcompany

TaxInvoice(xml)

Web-Ser-vices

client

client

client

Resultdoc

Standard

• Core Component Technical Specification v2.01, UN/CEFACT, 2003• XML Naming Design Rules v1.1, UN/CEFACT 2004• Data Type Catalogue, UN/CEFACT 2008• XML Signature Syntax and Processing, W3C/IETF, 2002• Simple Object Access Protocol v1.1, W3C, 2000• Simple Object Access Protocol v1.2, W3C, 2007• Web Service Addressing v1.0 Core, W3C, 2006• Web Service Security v1.1, OASIS, 2004• Cryptographic Message Syntax, IETF, 2004• 128bit Block Encryption Algorithm ARIA, KS, 2004• 128bit Block encryption Algorithm SEED, TTA, 2005

TaxInovicePackage

TaxInvoicePackage ::= SE-QUENCE {count InvoiceCount,taxInvoiceSet TaxInvoiceSet }

InvoiceCount ::= INTEGERTaxInvoiceSet ::= SET SIZE (1..100) OF TaxIvnoceDataTaxIvnoiceData ::= SEQUENCE {rvalue SignerRValue,taxInvoice TaxInvoice }

EnvelopedData

TaxInvoice (1-100)

XML

XMLDSig

• TaxInvoice is signed by taxinvoice issuer certificate• TaxInvoicePackage is a bundle of taxInvoice (1-100)• TaxInvoicePackage is CMS (Enveloped-data) – with NTS

public key

Transport

SOAP Envelope

Security

SecurityToken

Signature

SOAP Body(Request/Response data,

SOAP Fault)

SOAPHeader

Attachment(Enveloped TaxInvoicePakcage)

• SOAP v1.1 or v1.2• SOAP Messages with Attach-

ment• WS-Security v1.1• WS-Addressing v1.0• No SSL (instead Content en-

cryption)

TestBed

• Implemented products need to check interoperability

• Automatized test framework (ETSL)

• TaxInvoice structure, logical value, security(XMLDsig, VID validation)

• Message structure, logical value, security(WS-Security)

CompanyeTax Sys-

temTestBed

Check inter-operability

NTSSubmit TaxInvoice

Thanks

Young jun Bae

Torpedo CorpPhone: 82-2-552-7483FAX: 82-2-552-7480E-mail: yjbae@torpedo.co.krHomepage: www.torpedo.co.kr