Transcript Secure Data Transmission

Secure Data
Transmission
EDI-INT AS1, AS2, AS3
Kevin Grant
Goals of this Presentation
• Understanding Security Mechanisms
• Understanding Applicability Statements
– MDNs
– Secure Transmission Loop
– AS1, AS2, AS3
• Product Certification
AS1/AS2/AS3 Standards
•
•
Applicability Statements 1 (AS1), 2 (AS2), & 3 (AS3)
are the current specifications developed by EDI-INT
for transporting data via the Internet.
AS Standards specify how to exchange data, not
how to process data.
–
–
–
•
AS1 defines how to perform secure file transfers via SMTP
AS2 defines how to perform secure file transfers via HTTP
AS3 defines how to perform secure file transfers via FTP
Specify Security Services over a Specific
Communication protocol with the introduction of
Message Disposition Notifications (MDNs) to
complete the Secure Transmission Loop
AS1/AS2/AS3 Options
•
•
•
•
Encrypted or not encrypted
Signed or unsigned
Receipt or no receipt
Receipt signed, or not signed
AS1/AS2/AS3 Message Flow
Message
Encrypted
with
Recipient’s
Public Key
SMTP/
HTTP/
FTP
Recipient
Message
Decrypted
with
Recipient’s
Private Key
Outgoing
Message
Document
hash is
computed
Computed hash
compared with
transmitted hash
Signature/Hash
Applied and
Encrypted with
Sender’s
Private Key
Signature/hash
Decrypted with
Sender’s
Public Key
Signed MDN
back to
sender with
hash
Incoming
Message
Validated
Security Mechanisms
Three basic building blocks are used:
• Encryption is used to provide confidentiality, can
provide authentication and integrity protection
• Hash algorithms are used to provide integrity
protection, can provide authentication
• Digital signatures are used to provide
authentication, integrity protection, and nonrepudiation
One or more security mechanisms are combined to
provide a security service
Security Protocol
• A typical security protocol provides one or
more services
• Services are built from mechanisms
• Mechanisms are implemented using algorithms
Hash Functions
• Hashing is the transformation of a string of
characters into a shorter fixed-length value or
key that represents the original string.
• It is used to index and retrieve items in a
database because it is faster to find the item
using the shorter hashed key than to find it
using the original value.
Hash Functions
• It is also used in many encryption algorithms.
– Creates a unique “fingerprint” or message digest.
– Anyone can alter the data and calculate a new
hash value
– Message digest has to be protected in some way
Public-key Encryption
• Uses matched public/private key pairs
(Asymmetric)
• Anyone can encrypt with the public key,
only one person can decrypt with the
private key
Cryptography – Digital
Signatures
Here’s where the public-key algorithm and the hashing
algorithm work together:
Certificates
• A certificate is a public key that has
been digitally signed by a trusted third
party
– Certificate Authority (CA).
• A Certification Authority (CA) guarantees a
public key’s authenticity
MDNs
(Message Disposition Notifications)
• Document acknowledgment
– Non-repudiation of delivery (confirms the document WAS
received and by whom)
– Confirms that the recipient was able to decrypt
– Gives a status message, as appropriate
• Contains the receiver’s computed hash for
comparison against the one originally sent with
the message
• MDN may be signed by the recipient of the
original message
• Defined by your trading partner (optional)
MDN Request Headers
The MDN is requested by the “DispositionNotification-To” field found in the message
header:
From: [email protected]
AS2-Version: 1.1
AS2-From: AS2SENDER
AS2-To: AS2RECEIVER
Subject: G1 Test Case
Message-Id: <200207310834482A70BF63@\"~~foo~~\">
Disposition-Notification-To: [email protected]
Receipt-Delivery-Option: mailto:[email protected]
Disposition-Notification-Options: signed-receiptprotocol=optional,pkcs7-signature;
signed-receipt-micalg=optional,sha1
Content-Type: multipart/signed;
boundary="as2BouNdary1as2";
protocol="application/pkcs7-signature";
micalg=sha1
MDN Request Headers
The “Receipt-Delivery-Option” field is used to
request MDNs in an asynchronous manner. If this
field is not present, the MDN is returning via the
active HTTP session (AS2):
From: [email protected]
AS2-Version: 1.1
AS2-From: AS2SENDER
AS2-To: AS2RECEIVER
Subject: G1 Test Case
Message-Id: <200207310834482A70BF63@\"~~foo~~\">
Disposition-Notification-To: [email protected]
Receipt-Delivery-Option: mailto:[email protected]
Disposition-Notification-Options: signed-receiptprotocol=optional,pkcs7-signature;
signed-receipt-micalg=optional,sha1
Content-Type: multipart/signed;
boundary="as2BouNdary1as2";
protocol="application/pkcs7-signature"; micalg=sha1
MDN Request Headers
The “Disposition-Notification-Options” field
determines whether the MDN is to be signed
and identifies the preferred hash algorithm
(SHA-1 or MD5):
From: [email protected]
AS2-Version: 1.1
AS2-From: AS2SENDER
AS2-To: AS2RECEIVER
Subject: G1 Test Case
Message-Id: <200207310834482A70BF63@\"~~foo~~\">
Disposition-Notification-To: [email protected]
Receipt-Delivery-Option: mailto:[email protected]
Disposition-Notification-Options: signed-receiptprotocol=optional,pkcs7-signature; signed-receiptmicalg=optional,sha1
Content-Type: multipart/signed;
boundary="as2BouNdary1as2";
protocol="application/pkcs7-signature";
The “Secure Transmission Loop”
(STL)
• The originator sends a signed and
encrypted document with a request for a
signed receipt.
• The recipient decrypts the document,
verifies the signature, and returns a
signed receipt to the sender.
The “STL” In More Detail
•
•
•
Sender signs and encrypts the data using
S/MIME and sends requesting a signed receipt.
Receiver decrypts the message and verifies the
signature, resulting in verified integrity of the
data and authenticity of the sender.
The receiving organization returns a signed
receipt (message disposition notification). This
signed receipt contains the hash of the
message from the received message, so
sender knows message was verified and/or
decrypted properly.
Receiving via AS1/AS2/AS3
(Inbound Documents)
1. Signed/encrypted document is received
2. Document is decrypted (using receiver’s private key)
and hash is computed
3. Digital signature is checked to validate sender
4. Transmitted hash is decrypted (using sender’s public
key) and compared to the “computed” hash
5. If the hashes are the same, the document is
identical to the one transmitted
6. MDN is sent to confirm message status
Sending via AS1/AS2/AS3
(Outbound Documents)
1. Document is encrypted (using receiver’s public key)
and hash is computed
2. Hash is encrypted (using sender’s private key) and
attached to the digital signature block (which
may or may not be encrypted)
3. Message (document + signature) is transmitted
4. Partner receives message and attempts to
decrypt and validate
5. MDN is received confirming message status
AS1/AS2/AS3 Message Flow
Message
Encrypted
with
Recipient’s
Public Key
SMTP/
HTTP/
FTP
Recipient
Message
Decrypted
with
Recipient’s
Private Key
Outgoing
Message
Document
hash is
computed
Computed hash
compared with
transmitted hash
Signature/Hash
Applied and
Encrypted with
Sender’s
Private Key
Signature/hash
Decrypted with
Sender’s
Public Key
Signed MDN
back to
sender with
hash
Incoming
Message
Validated
AS1 - Sample
Received: from gw.somecompany.com (gw.somecompany.com
[10.1.1.2])
by mail.softshare.com (8.9.1/8.9.1) with ESMTP id
RAA29018
for <[email protected]>; Wed, 25 Feb 2004 17:56:50 0800 (PST)
Message-ID: <[email protected]>
Date: Thu, 26 Feb 2004 01:56:11 GMT
Subject: 850:ORDERNO-12345678
From: [email protected]
To: [email protected]
Disposition-Notification-To:
[email protected]
Disposition-Notification-Options: signed-receiptprotocol=optional,
pkcs7-signature; signed-receipt-micalg=optional, sha1, md5
Content-Type: application/pkcs7-mime; smime-type=envelopeddata; name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
AS2 - Sample
POST /invoke/wm.EDIINT/receive HTTP/1.0
Host: 208.234.160.12:80
User-Agent: AS2 Company Server
Date: Wed, 31 Jul 2002 13:34:50 GMT
From: [email protected]
AS2-Version: 1.1
AS2-From: "\" as2Name \""
AS2-To: 0123456780000
Subject: G1 Test Case
Message-Id: <200207310834482A70BF63@\"~~foo~~\">
Disposition-Notification-To: [email protected]
Disposition-Notification-Options: signed-receiptprotocol=optional,pkcs7-signature; signed-receiptmicalg=optional,sha1
Content-Type: multipart/signed; boundary="as2BouNdary1as2";
protocol="application/pkcs7-signature"; micalg=sha1
Content-Length: 2464
AS3 - Sample
Date: Wed, 31 Jul 2002 13:34:50 GMT
AS3-Version: 1.0
AS3-From: cyclone
AS3-To: "trading partner"
Message-Id: <[email protected]>
Disposition-Notification-To: ftp://host:port/mdnbox
Disposition-Notification-Options: signed-receiptprotocol=optional,pkcs7-signature; signed-receiptmicalg=optional,sha1
Content-Type: multipart/signed; boundary="as3BouNdary1as3";
protocol="application/pkcs7-signature"; micalg=sha1
Content-Length: 3075
--as3BouNdary1as3
Content-Type: application/edi-x12
Content-Disposition: Attachment; filename=rfc1767.dat
[ISA ...EDI transaction data...IEA...]
--as3BouNdary1as3
Content-Type: application/pkcs7-signature
[omitted binary pkcs7 signature data]
--as3BouNdary1as3
AS2 Certification
• All ‘standards’ created equal?
• Based on clear public specifications that
enjoy wide usage because of this
• Certifying commonly-used and welldocumented standards causes time delays
in implementation and adds unnecessary
costs to the end product
Drummond Certification
• Founded in 1999
• Drummond Group Inc. (DGI) is a privately
held company that conducts
interoperability and conformance testing
• DGI’s role is to administer the test
Open AS2
• The OpenAS2 project is a collaborative
effort to develop an open source
application that implements the EDIINT
AS2 Standard
• Self-paced, performed in-house, and the
project itself does not profit from the
testing process
Questions?