Security. Learning Objectives. This module will help you...

Transcription

1 Security 5-1 Learning Objectives This module will help you... Understand the security infrastructure supported by JXTA Understand JXTA's use of TLS for end-to-end security 5-2

2 Highlights Desired security features Quick overview of TLS JXTA TLS requirements Peers as certificate authorities A peer's personal security environment The JXTA Virtual Transport (JVT) Implementing TLS on the JVT Group authentication with TLS Supported TLS Cipher Suites How we compare 5-3 Desired Security Features Privacy No eavesdropping on communication Authentication You are who you say you are Integrity What I send is what you receive Non-repudiation I cannot take back a transaction I completed earlier 5-4

3 Desired Non-Security Features Standards Based Don't reinvent the wheel Protocols Equal opportunity for all implementations Building Blocks Reuse existing open source projects 5-5 TLS Overview Transport Layer Security (TLS) is defined in rfc2246 TLS is the IETF Security Working Group's continuation of the development of SSL v3 Provides communications privacy over the Internet It is designed to prevent eavesdropping, tampering or message forgery 5-6

4 TLS Overview (continued) Messages are private Symmetric cryptography is used for data encryption (3DES, RC4, AES, etc.) The connection is reliable Message transport includes a message integrity check using a keyed MAC Secure hash functions are used (MD5, SHA1) 5-7 TLS Overview (continued) TLS has an handshake protocol followed by an application data protocol TLS Handshake protocol permits the client and server To authenticate each other with X509.v3 certificates Asymmetric or public key cryptography is used (RSA, DSS, etc.) To negotiate an encryption algorithm and cryptographic keys before data is transmitted TLS application data protocol permits the secure exchange of application data with symmetric cipher algorithms 5-8

5 JXTA TLS Requirements Certificates In a P2P network, each peer can be both a TLS client and a TLS server We require client and server authentication Client initiates contact Client Server sends its signed X509 cert Server sends send certificate request Server Client cert and signature Server's/Client's root cert is used to verify signature,and thus authenticate the server/client 5-9 JXTA TLS Requirements J2SE Implementation A full Java TLS implementation is required We chose Claymore Systems puretls by Eric Rescorla who is a very active member of the IETF TLS working group. The code is extremely well tested and also supports SSL.v2 and SSL.v3! Public key and symmetric key algorithms are required by TLS We chose Cryptix because puretls requires it. Cryptix gives complete TLS cipher suite support 5-10

6 JXTA TLS Requirements Reliable Transport Client IMAPv4 TLS TCP IP Typical Internet Security Stack Transaction (read msg) IMAPv4 Command TLS Records Reliable byte stream Packets Physical layer Server IMAPv4 TLS TCP IP TLS requires a reliable transport like TCP/IP 5-11 JXTA TLS Requirements Summary X509.V3 certificate generation Root certificates Service certificates signed by the root Root certificate distribution Private Personal Security Environment Keep passwords and private keys secret End-to-end reliable byte stream transport 5-12

7 1) Peers as Certificate Authorities We want $0 cost as the entry level security Certificate Authorities (CA) charge for signed user certificates We want JXTA to work for both the $0 cost entry level as well as CA's. For the $0 cost entry level security --> every peer is its own CA Each peer generates a root certificate and user certificates issued by this root CA (signed by the root CA's private key) 5-13 The Poblano Trust Spectrum Towards Conventional Internet Trust Model PGP-like Self-signed Co-signed Peer Group member as CA Centralized CA Chat Games Chat - IPR Discussions Financial Transactions 5-14

8 2) Root Certificate Distribution Root certificates are distributed in peer advertisements for entry level $0 cost security Secure communication in JXTA is only possible if peers possess each other's peer advertisements, and thus, root certs This distribution scheme is vulnerable to a "man-in-the-middle" attack True CA generated root certificates may be part of a JXTA binary and distributed with the binary. This is how root certs are distributed with web browsers The JXTA TLS implementation can be adapted to either approach, both, or models between the two. For example: Root certificates can require multiple signatures as in PGP. This is more difficult to attack and is still free 5-15 Private Personal Security Environment To Protect Passwords and Private Keys Directory structure: pse/ client/ client X509.v3 certs + private keys peer.phrase (passphrase) etc/ passwd file root/ root X509.v3 certs + private keys Private keys are encrypted with the passphrase + salt and use DES-EDE3-CBC (Triple DES cipher block chaining mode) The passphrase is a SHA1 hash (128 passes) of 128 psuedo random bytes. It is encrypted with RC4 (128 bit key derived from the user password). The passwd file is the SHA1+ salt hash (multiple passes) of the password. 5-16

9 Typical User Certificate in Text Format Version: 3 IssuerDN: O= L=SF, C=US, CN=secure-CA, OU=98FD486C4FBA4E9588C2 Start Date: Wed Nov 28 13:55:54 PST 2001 Final Date: Mon Nov 28 13:55:54 PST 2011 SubjectDN: O= L=SF, C=US, CN=secure,OU=6FC145F38A4F70A89C02 Public Key: RSA Public Key modulus: 843d01cc08ac4f d2cdb769f46cb91d cfce360f636a6b160edfc993150ded0737a 45b31835b09c2ae1767bd5b8a9ef5b95ec923d3a091775c4f60f037a67af55262bf6e05fe2062ea05 194a6e8ed73a78b2966fe49858d66abda1fe155dea2248b891ef8311b d3a2ce4484dd0eb9 cd51eb797a0a1 public exponent: 11 Signature Algorithm: SHA1WithRSAEncryption Signature: a34f cfc94dc91c263111f354b 5a1efab5debf1e421f32b04c6f637a25d47752d5 a970e5126dbeda7f335ba40e65e3ff019b2775de b8141dac322271fa1c296afac26bc1a1d0dba9cb 6cacfa06430a7f4eae508f46ee3a4416bdb3304a b4f831c66b79338b3e83c57e9bf52bb498ca7b e74ba0ede 5-17 Same User Certificate ASN.1 DER Encoded and in Base BEGIN CERTIFICATE----- MIICNTCCAZ6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBkMRUwEwYDVQQKEwx3d3cu anh0ys5vcmcxczajbgnvbactalngmqswcqydvqqgewjvuzesmbaga1ueaxmjc2vj dxjllunbmr0wgwydvqqlexq5oezendg2qzrgqke0rtk1odhdmjaefw0wmtexmjgy MTU1NTRaFw0xMTExMjgyMTU1NTRaMGExFTATBgNVBAoTDHd3dy5qeHRhLm9yZzEL MakGA1UEBxMCU0YxCzAJBgNVBAYTAlVTMQ8wDQYDVQQDEwZzZWN1cmUxHTAbBgNV BAsTFDZGQzE0NUYzOEE0RjcwQTg5QzAyMIGbMAsGCSqGSIb3DQEBAQOBiwAwgYcC gyeahd0bzaistwjegycnlnt2n0blkdkiijbpzjypy2prfg7fyzmvde0hn6rbmynb CcKuF2e9W4qe9bleySPToJF3XE9g8DemevVSYr9uBf4gYuoFGUpujtc6eLKWb+SY WNZqvaH+FV3qIki4ke+DEbUpJhVNOizkSE3Q65zVHreXoKECAREwDQYJKoZIhvcN AQEFBQADgYEAh3cCmjT0KZAibPyU3JHCYxEfNUtaHvq13r8eQh8ysExvY3ol1HdS 1alw5RJtvtp/M1ukDmXj/wGbJ3XeuBQdrDIicfocKWr6wmvBodDbqctsrPoGQwp/ Tq5Qj0buOkQWvbMwSrT4McZreTOLPoPFfpv1K7SYynt3NRNAnnS6Dt4= -----END CERTIFICATE----- Note: It appears like this in the peer advertisement. 5-18

10 Full TLS Java Implementation Claymore Systems puretls Requires Cryptix32 for TLS cipher suite support Cryptix-ans1 for asn1 code Bouncy-Castle We've stripped the jar and only use the code required for generating certificates JXTA Security Library Used for securing the local data storage like the personal security environment 5-19 Support puretls Ciphersuites PureTLS supports all TLS ciphersuites, and we currently use TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA uses 1024 bit modulus 3DES uses a 192 bit key - three 56 bit keys, each with 8 bits of parity. We can choose any from the following: TLS_RSA_EXPORT_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA There are theoretical attacks against RC4, but it has the advantage of being super fast. It might make sense to permit applications that exchange large amounts of content to select this ciphersuite. 5-20

11 JXTA-C TLS Implementation Plan to use available open source modules: Bouncy-Castle for certificate generation Cryptix for Algorithms Several open TLS implementations to choose from 5-21 End-to-end Reliable Byte Stream Transport Peer-to-peer communication is by its very nature unreliable How do we place a reliability requirement appropriately into the JXTA Virtual Transport? This is possible because of the flexibility of the JXTA protocol stack JXTA Virtual Transport implements a reliable bi-directional byte stream Next Slide 5-22

12 JXTA Virtual Transport Data Pipe Discovery + resolver Peer Adv Peer Adv Resolver JXTA Virtual Network Peer Endpoint + PeerID Peer Endpoint + PeerID Resolver Real Transport 5-23 JXTA Virtual Transport + Pluggable TLS Transport Secure Pipe Secure Endpoint TLS Transport + PeerID Peer Endpoint + PeerID Discovery + resolver Resolver Resolver Resolver Peer Adv + Secure Endpoint TLS Transport Peer Endpoint + PeerID Real Transport 5-24

13 Piping Application Binary Messages Through the Reliable TLS Transport Pipe JXTA Binary Message of arbitrary length TLS Transport Have no flowcontrol May arrive out of order May be dropped TLS Records as sequenced elements in JXTA messages on the JXTA virtual network We use a reliable message protocol to maintain flowcontrol and guarantee complete, ordered delivery 5-25 Reliable TLS Transport Each TLS Record is an element of a sequenced JXTA binary message Input and retransmit queues are limited to 25 messages Sent messages remain on the retransmit queue until acknowledged Received messages are selectively acknowledged (SACK) A SACK is a list of the sequence numbers of all messages in the input queue Sender will not overrun the receiver's input queue 5-26

14 Reliable TLS Transport (continued) The receipt of a SACK causes Sender to remove acknowledged messages from the retransmission queue Immediately fill the hole (messages must be processed in sequence) up to the output window size. For example: Retrans Queue = 98,99,100,101,102,103,104 SACK = 99,100,102,104 99,100,102, and 104 are removed from the retransmission queue 98, 101 and 103 are retransmitted 5-27 Reliable TLS Transport (continued) Average round trip time (RTT) is used to calculate the retransmit time out (RTO), 1 sec < RTO < 5 secs Given a non-empty retransmission queue: No SACKS received for longer than the RTO will trigger a retransmission of 1 to 5 messages depending on receiver's input queue size 5-28

15 TLS Virtual Transport Peer1 Peer2 Messages M1 M2 Mn M1 M2 Mn Pipes P1 P2 Pn Endpoint P1 P2 Pn Endpoint TLS Records TLS Transport TLS Transport One TLS Connection between Peer1 and Peer2 The messages for all pipes are multiplexed through a single TLS Connection (only one handshake is required) If the underlying transport is TCP/IP, then a single connection is used TLS Virtual Transport App. Data App. Data JXTA messages I/O Pipes PeerID1 PeerID2 peerid1 peerid2 Virtual TLS Transport PeerID3 Relay Firewall PeerID3 PeerID4 Relay PeerID4 Firewall JXTA messages Relay PeerID5 PeerID6 peerid5 I/O Pipes PeerID6 JXTA Virtual Network 5-30

16 Group Authentication with TLS PeerGroup creator (PGC) has initial authority to grant authentication privileges. On first contact a peer: Is given the PGC's group root certificate Makes a Certificate Service Request to the PGC (puretls has CSR code) Sends RSA public key, Distinguished name, etc... Is granted a group membership certificate signed with the private key of the PGC's root cert. The above info is locally protected in the peer's personal security environment and is accessible with the peer's password 5-31 Group Authentication with TLS (cont.) When a peergroup member, p1, contacts another peergroup member, p2, the latter member uses the optional client Certificate Request of the TLS Handshake. Client Server Certificate Request Certificate CertificateVerify (Cert + private key generated signature are sent) 5-32

17 How Does JXTA Compare? The JXTA TLS implementation offers as much security strength as any available on the Internet that uses SSL.v3 TLS is more resilient than SSL.V3, i.e., more difficult to attack E.g.: It uses XOR rather than concatenation when using combinations of MD5 and SHA1 hashes to compute various parameters. This means that if one finds an attack against SHA1 then MD5 carries the same weight (XOR) and the data cannot be attacked End Security 5-34