Secure Data Transmission

1. Secure Data Transmission EDI-INT AS1, AS2, AS3 Kevin Grant

2. Goals of this Presentation • Understanding Security Mechanisms • Understanding Applicability Statements • MDNs • Secure Transmission Loop • AS1, AS2, AS3 • Product Certification

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

4. AS1/AS2/AS3 Options • Encrypted or not encrypted • Signed or unsigned • Receipt or no receipt • Receipt signed, or not signed

5. Document hash is computed Message Encrypted with Recipient’s Public Key Recipient Outgoing Message SMTP/HTTP/FTP Computed hash compared with transmitted hash Signature/Hash Applied and Encrypted with Sender’s Private Key Signature/hash Decrypted with Sender’s Public Key Message Decrypted with Recipient’s Private Key Incoming MessageValidated Signed MDN back to sender with hash AS1/AS2/AS3 Message Flow

6. 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 non-repudiation One or more security mechanisms are combined to provide a security service

7. Security Protocol • A typical security protocol provides one or more services • Services are built from mechanisms • Mechanisms are implemented using algorithms

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

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

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

11. Cryptography – Digital Signatures Here’s where the public-key algorithm and the hashing algorithm work together:

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

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

14. MDN Request Headers The MDN is requested by the “Disposition-Notification-To” field found in the message header: From: mrAS2@as2.com AS2-Version: 1.1 AS2-From: AS2SENDER AS2-To: AS2RECEIVER Subject: G1 Test Case Message-Id: <200207310834482A70BF63@\"~~foo~~\"> Disposition-Notification-To: mrAS2@as2.com Receipt-Delivery-Option:mailto:AS2@as2.com Disposition-Notification-Options: signed-receipt- protocol=optional,pkcs7-signature; signed-receipt-micalg=optional,sha1 Content-Type: multipart/signed; boundary="as2BouNdary1as2"; protocol="application/pkcs7-signature"; micalg=sha1

15. 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: mrAS2@as2.com AS2-Version: 1.1 AS2-From: AS2SENDER AS2-To: AS2RECEIVER Subject: G1 Test Case Message-Id: <200207310834482A70BF63@\"~~foo~~\"> Disposition-Notification-To: mrAS2@as2.com Receipt-Delivery-Option:mailto:AS2@as2.com Disposition-Notification-Options: signed-receipt- protocol=optional,pkcs7-signature; signed-receipt-micalg=optional,sha1 Content-Type: multipart/signed; boundary="as2BouNdary1as2"; protocol="application/pkcs7-signature"; micalg=sha1

16. 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: mrAS2@as2.com AS2-Version: 1.1 AS2-From: AS2SENDER AS2-To: AS2RECEIVER Subject: G1 Test Case Message-Id: <200207310834482A70BF63@\"~~foo~~\"> Disposition-Notification-To: mrAS2@as2.com Receipt-Delivery-Option:mailto:AS2@as2.com Disposition-Notification-Options: signed-receipt- protocol=optional,pkcs7-signature; signed-receipt-micalg=optional,sha1 Content-Type: multipart/signed; boundary="as2BouNdary1as2"; protocol="application/pkcs7-signature"; micalg=sha1

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

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

19. Receiving via AS1/AS2/AS3(Inbound Documents) • Signed/encrypted document is received • Document is decrypted (using receiver’s private key) and hash is computed • Digital signature is checked to validate sender • Transmitted hash is decrypted (using sender’s public key) and compared to the “computed” hash • If the hashes are the same, the document is identical to the one transmitted • MDN is sent to confirm message status

20. Sending via AS1/AS2/AS3(Outbound Documents) • Document is encrypted (using receiver’s public key) and hash is computed • Hash is encrypted (using sender’s private key) and attached to the digital signature block (which may or may not be encrypted) • Message (document + signature) is transmitted • Partner receives message and attempts to decrypt and validate • MDN is received confirming message status

21. Document hash is computed Message Encrypted with Recipient’s Public Key Recipient Outgoing Message SMTP/HTTP/FTP Computed hash compared with transmitted hash Signature/Hash Applied and Encrypted with Sender’s Private Key Signature/hash Decrypted with Sender’s Public Key Message Decrypted with Recipient’s Private Key Incoming MessageValidated Signed MDN back to sender with hash AS1/AS2/AS3 Message Flow

22. 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 <AS1@softshare.com>; Wed, 25 Feb 2004 17:56:50 -0800 (PST) Message-ID: <1077760571490.12345686869@somecompany.com> Date: Thu, 26 Feb 2004 01:56:11 GMT Subject: 850:ORDERNO-12345678 From: edi@somecompany.com To: AS1@softshare.com Disposition-Notification-To: somecompanyprodedi1@somecompany.com Disposition-Notification-Options: signed-receipt-protocol=optional, pkcs7-signature; signed-receipt-micalg=optional, sha1, md5 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m

23. 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: mrAS2@as2.com AS2-Version: 1.1 AS2-From: "\" as2Name \"" AS2-To: 0123456780000 Subject: G1 Test Case Message-Id: <200207310834482A70BF63@\"~~foo~~\"> Disposition-Notification-To: mrAS2@as2.com Disposition-Notification-Options: signed-receipt-protocol=optional,pkcs7-signature; signed-receipt-micalg=optional,sha1 Content-Type: multipart/signed; boundary="as2BouNdary1as2"; protocol="application/pkcs7-signature"; micalg=sha1 Content-Length: 2464

24. AS3 - Sample Date: Wed, 31 Jul 2002 13:34:50 GMT AS3-Version: 1.0 AS3-From: cyclone AS3-To: "trading partner" Message-Id: <200207310834482A70BF63@host.com> Disposition-Notification-To: ftp://host:port/mdnbox Disposition-Notification-Options: signed-receipt- protocol=optional,pkcs7-signature; signed-receipt-micalg=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

25. AS2 Certification • All ‘standards’ created equal? • Based on clear public specifications that enjoy wide usage because of this • Certifying commonly-used and well-documented standards causes time delays in implementation and adds unnecessary costs to the end product

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

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

28. Questions?