Security 5 -1 Learning Objectives This

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-toend security 5 -1

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

Desired Security Features ● Privacy – ● Authentication – ● You are who you say you are Integrity – ● No eavesdropping on communication What I send is what you receive Non-repudiation – I cannot take back a transaction I completed earlier 5 -1

Desired Non-Security Features ● Standards Based – ● Protocols – ● Don't reinvent the wheel Equal opportunity for all implementations Building Blocks – Reuse existing open source projects 5 -1

TLS Overview ● ● Transport Layer Security (TLS) is defined in rfc 2246 TLS is the IETF Security Working Group's continuation of the development of SSL v 3 Provides communications privacy over the Internet It is designed to prevent eavesdropping, tampering or message forgery 5 -1

TLS Overview (continued) ● Messages are private – ● Symmetric cryptography is used for data encryption (3 DES, RC 4, AES, etc. ) The connection is reliable – Message transport includes a message integrity check using a keyed MAC – Secure hash functions are used (MD 5, SHA 1) 5 -1

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 X 509. v 3 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 -1

JXTA TLS Requirements — Certificates In a P 2 P network, each peer can be both a ● ● TLS client and a TLS server We require client and server authentication Client initiates contact Server sends its signed X 509 cert Client 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 -1

JXTA TLS Requirements J 2 SE Implementation ● A full Java TLS implementation is required – We chose Claymore Systems pure. TLS 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. v 2 and SSL. v 3! Public key and symmetric key algorithms are required by TLS – We chose Cryptix because pure. TLS requires it. Cryptix gives complete TLS cipher suite support 5 -1

JXTA TLS Requirements Reliable Transport Typical Internet Security Stack Email Client IMAPv 4 TLS TCP IP Transaction (read msg) IMAPv 4 Command TLS Records Reliable byte stream Packets Email Server IMAPv 4 TLS TCP IP TLS requires a reliable transport like TCP/IP Physical layer 5 -1

JXTA TLS Requirements Summary ● X 509. V 3 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 -1

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

The Poblano Trust Spectrum Towards Conventional Internet Trust Model PGP-like Self-signed Co-signed Chat Games Peer Group member as CA Centralized CA Chat - IPR Financial Discussions. Transactions 5 -1

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

Private Personal Security Environment To Protect Passwords and Private Keys Directory structure: pse/ client X 509. v 3 certs + private keys peer. phrase (passphrase) etc/ passwd file root/ root X 509. v 3 certs + private keys – – – Private keys are encrypted with the passphrase + salt and use DES-EDE 3 -CBC (Triple DES cipher block chaining mode) The passphrase is a SHA 1 hash (128 passes) of 128 psuedo random bytes. It is encrypted with RC 4 (128 bit key derived from the user password). The passwd file is the SHA 1+ salt hash (multiple passes) of the password. 5 -1

Typical User Certificate in Text Format Version: 3 Issuer. DN: O=www. jxta. org, L=SF, C=US, CN=secure-CA, OU=98 FD 486 C 4 FBA 4 E 9588 C 2 Start Date: Wed Nov 28 13: 55: 54 PST 2001 Final Date: Mon Nov 28 13: 55: 54 PST 2011 Subject. DN: O=www. jxta. org, L=SF, C=US, CN=secure, OU=6 FC 145 F 38 A 4 F 70 A 89 C 02 Public Key: RSA Public Key modulus: 843 d 01 cc 08 ac 4 f 024419870 d 2 cdb 769 f 46 cb 91 d 9222236 cfce 360 f 636 a 6 b 160 edfc 993150 ded 0737 a 45 b 31 835 b 09 c 2 ae 1767 bd 5 b 8 a 9 ef 5 b 95 ec 923 d 3 a 091775 c 4 f 60 f 037 a 67 af 55262 bf 6 e 05 fe 2062 ea 05194 a 6 e 8 ed 7 3 a 78 b 2966 fe 49858 d 66 abda 1 fe 155 dea 2248 b 891 ef 8311 b 52926154 d 3 a 2 ce 4484 dd 0 eb 9 cd 51 eb 797 a 0 a 1 public exponent: 11 Signature Algorithm: SHA 1 With. RSAEncryption Signature: 8777029 a 34 f 42990226 cfc 94 dc 91 c 263111 f 354 b 5 a 1 efab 5 debf 1 e 421 f 32 b 04 c 6 f 637 a 25 d 47752 d 5 a 970 e 5126 dbeda 7 f 335 ba 40 e 65 e 3 ff 019 b 2775 de b 8141 dac 322271 fa 1 c 296 afac 26 bc 1 a 1 d 0 dba 9 cb 6 cacfa 06430 a 7 f 4 eae 508 f 46 ee 3 a 4416 bdb 3304 a b 4 f 831 c 66 b 79338 b 3 e 83 c 57 e 9 bf 52 bb 498 ca 7 b 77 3513409 e 74 ba 0 ede 5 -1

Same User Certificate ASN. 1 DER Encoded and in Base 64 -----BEGIN CERTIFICATE----MIICNTCCAZ 6 g. Aw. IBAg. IBATANBgkqhki. G 9 w 0 BAQUFADBk. MRUw. Ew. YDVQQKEwx 3 d 3 cu anh 0 YS 5 vcmcx. Cz. AJBg. NVBAc. TAl. NGMQsw. CQYDVQQGEw. JVUz. ESMBAGA 1 UEAx. MJc 2 Vj d. XJl. LUNBMR 0 w. Gw. YDVQQLEx. Q 5 OEZENDg 2 Qz. RGQk. E 0 RTk 1 ODh. DMj. Ae. Fw 0 w. MTEx. Mjgy MTU 1 NTRa. Fw 0 x. MTEx. Mjgy. MTU 1 NTRa. MGEx. FTATBg. NVBAo. TDHd 3 dy 5 qe. HRh. Lm 9 y. Zz. EL Mak. GA 1 UEBx. MCU 0 Yx. Cz. AJBg. NVBAYTAl. VTMQ 8 w. DQYDVQQDEw. Zz. ZWN 1 cm. Ux. HTAb. Bg. NV BAs. TFDZGQz. E 0 NUYz. OEE 0 Rjcw. QTg 5 Qz. Ay. MIGb. MAs. GCSq. GSIb 3 DQEBAQOBiw. Awg. Yc. C g. YEAh. D 0 Bz. Ais. Tw. JEGYc. NLNt 2 n 0 b. Lkdki. Ijb. Pzj. YPY 2 pr. Fg 7 fy. ZMVDe 0 HN 6 Rb. MYNb Cc. Ku. F 2 e 9 W 4 qe 9 bley. SPTo. JF 3 XE 9 g 8 Demev. VSYr 9 u. Bf 4 g. Yuo. FGUpujtc 6 e. LKWb+SY WNZqva. H+FV 3 q. Iki 4 ke+DEb. Up. Jh. VNOizk. SE 3 Q 65 z. VHre. Xo. KECAREw. DQYJKo. ZIhvc. N AQEFBQADg. YEAh 3 c. Cmj. T 0 KZAib. Py. U 3 JHCYx. Ef. NUta. Hvq 13 r 8 e. Qh 8 ys. Exv. Y 3 ol 1 Hd. S 1 alw 5 RJtvtp/M 1 uk. Dm. Xj/w. Gb. J 3 Xeu. BQdr. DIicfoc. KWr 6 wmv. Bod. Dbqctsr. Po. GQwp/ Tq 5 Qj 0 bu. Ok. QWvb. Mw. Sr. T 4 Mc. Zre. TOLPo. PFfpv 1 K 7 SYynt 3 NRNAnn. S 6 Dt 4= -----END CERTIFICATE----- Note: It appears like this in the peer advertisement. 5 -1

Full TLS Java 1. 3. 1 Implementation ● Claymore Systems pure. TLS – Requires ● ● ● Cryptix-ans 1 for asn 1 code Bouncy-Castle – ● Cryptix 32 for TLS cipher suite support 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 -1

Support pure. TLS Ciphersuites ● Pure. TLS supports all TLS ciphersuites, and we currently use – TLS_RSA_WITH_3 DES_EDE_CBC_SHA ● ● ● RSA uses 1024 bit modulus 3 DES 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_RC 4_128_MD 5 – TLS_RSA_WITH_RC 4_128_SHA ● ● There are theoretical attacks against RC 4, 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 -1

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

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

JXTA Virtual Transport Data Pipe Discovery + resolver Peer Adv JXTA Virtual Network Peer Adv Resolver Peer Endpoint Resolver + Peer. ID Peer Endpoint + Peer. ID Real Transport 5 -1

JXTA Virtual Transport + “Pluggable” TLS Transport Secure Pipe Secure Endpoint Discovery + resolver Peer Adv + Secure Endpoint Resolver TLS Transport Resolver + Peer. ID Peer Endpoint + Peer. ID Resolver TLS Transport Peer Endpoint + Peer. ID Real Transport 5 -1

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

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

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

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

TLS Virtual Transport Peer 2 Peer 1 Messages M 1 M 2 Pipes P 1 Mn P 2 Pn M 1 M 2 P 1 Mn P 2 Endpoint TLS Records Endpoint TLS Transport Pn TLS Transport One TLS Connection between Peer 1 and Peer 2 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. 5 -1

TLS Virtual Transport App. Data JXTA messages I/O Pipes JXTA messages Virtual TLS Transport I/O Pipes Peer. ID 3 Peer. ID 1 Relay Peer. ID 4 Peer. ID 2 Firewall Peer. ID 3 Relay peer. ID 1 Relay Peer. ID 4 peer. ID 2 Firewall Peer. ID 6 Peer. ID 5 Peer. ID 6 peer. ID 5 JXTA Virtual Network 5 -1

Group Authentication with TLS ● Peer. Group 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 (pure. TLS 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 -1

Group Authentication with TLS (cont. ) ● When a peergroup member, p 1, contacts another peergroup member, p 2, the latter member uses the optional client Certificate Request of the TLS Handshake. Client Server Certificate Request Certificate. Verify (Cert + private key generated signature are sent) 5 -1

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

End – Security 5 -1