Security

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

3
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

4
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
Desired Non-Security Features

• Standards Based
• Don't reinvent the wheel
• Protocols
• Equal opportunity for all implementations
• Building Blocks
• Reuse existing open source projects

6
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

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

8
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

9
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
Server
Client
Server sends its signed X509 cert
Server sends send certificate request
Client cert and signature
Server's/Client's root cert is used to verify
signature,and thus authenticate the server/client
10
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

11
JXTA TLS Requirements
Reliable Transport
Typical Internet Security Stack
Transaction (read msg)
Email Server
Email Client
IMAPv4
IMAPv4
IMAPv4 Command
TLS
TLS
TLS Records
Reliable byte stream
TCP
TCP
TLS requires a reliable transport like TCP/IP
IP
IP
Packets
Physical layer
12
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

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

14
The Poblano Trust Spectrum
Towards Conventional Internet Trust Model
PGP-like
Centralized CA
Self-signed
Co-signed
Peer Group member as CA
Chat Games
Chat - IPR Discussions
Financial Transactions
15
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

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

17
Typical User Certificate in Text Format

• Version 3
• IssuerDN Owww.jxta.org, LSF, CUS,
  CNsecure-CA, OU98FD486C4FBA4E9588C2
• Start Date Wed Nov 28 135554 PST 2001
• Final Date Mon Nov 28 135554 PST 2011
• SubjectDN Owww.jxta.org, LSF, CUS,
  CNsecure,OU6FC145F38A4F70A89C02
• Public Key RSA Public Key
• modulus 843d01cc08ac4f024419870d2cdb769f46c
  b91d9222236cfce360f636a6b160edfc993150ded0737a45b3
  1835b09c2ae1767bd5b8a9ef5b95ec923d3a091775c4f60f03
  7a67af55262bf6e05fe2062ea05194a6e8ed73a78b2966fe49
  858d66abda1fe155dea2248b891ef8311b52926154d3a2ce44
  84dd0eb9cd51eb797a0a1
• public exponent 11
• Signature Algorithm SHA1WithRSAEncryption
  Signature 8777029a34f42990226cfc94dc91c26
  3111f354b
  5a1efab5debf1e421f32b04c6f637a25d47752d5
  a970e5126dbeda7f335ba40e65e3ff019b27
  75de b8141dac322271fa1c296a
  fac26bc1a1d0dba9cb
  6cacfa06430a7f4eae508f46ee3a4416bdb3304a
  b4f831c66b79338b3e83c57e9bf52bb498ca
  7b77
  3513409e74ba0ede

18
Same User Certificate
ASN.1 DER Encoded and in Base64

• -----BEGIN CERTIFICATE-----
• MIICNTCCAZ6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBkMRUwEw
  YDVQQKEwx3d3cu
• anh0YS5vcmcxCzAJBgNVBAcTAlNGMQswCQYDVQQGEwJVUzESMB
  AGA1UEAxMJc2Vj
• dXJlLUNBMR0wGwYDVQQLExQ5OEZENDg2QzRGQkE0RTk1ODhDMj
  AeFw0wMTExMjgy
• MTU1NTRaFw0xMTExMjgyMTU1NTRaMGExFTATBgNVBAoTDHd3dy
  5qeHRhLm9yZzEL
• MakGA1UEBxMCU0YxCzAJBgNVBAYTAlVTMQ8wDQYDVQQDEwZzZW
  N1cmUxHTAbBgNV
• BAsTFDZGQzE0NUYzOEE0RjcwQTg5QzAyMIGbMAsGCSqGSIb3DQ
  EBAQOBiwAwgYcC
• gYEAhD0BzAisTwJEGYcNLNt2n0bLkdkiIjbPzjYPY2prFg7fyZ
  MVDe0HN6RbMYNb
• CcKuF2e9W4qe9bleySPToJF3XE9g8DemevVSYr9uBf4gYuoFGU
  pujtc6eLKWbSY
• WNZqvaHFV3qIki4keDEbUpJhVNOizkSE3Q65zVHreXoKECAR
  EwDQYJKoZIhvcN
• AQEFBQADgYEAh3cCmjT0KZAibPyU3JHCYxEfNUtaHvq13r8eQh
  8ysExvY3ol1HdS
• 1alw5RJtvtp/M1ukDmXj/wGbJ3XeuBQdrDIicfocKWr6wmvBod
  DbqctsrPoGQwp/
• Tq5Qj0buOkQWvbMwSrT4McZreTOLPoPFfpv1K7SYynt3NRNAnn
  S6Dt4
• -----END CERTIFICATE-----
• Note It appears like this in the peer
  advertisement.

19
Full TLS Java 1.3.1 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

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

21
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

22
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
23
JXTA Virtual Transport
Data Pipe
Peer Adv
Discovery resolver
JXTA Virtual Network
Peer Adv
Peer Endpoint PeerID
Resolver
Peer Endpoint PeerID
Real Transport
Resolver
24
JXTA Virtual Transport Pluggable TLS Transport
Peer Adv Secure Endpoint
Secure Pipe
Discovery resolver
TLS Transport
Secure Endpoint
Resolver
Peer Endpoint PeerID
Resolver
TLS Transport PeerID
Real Transport
Peer Endpoint PeerID
Resolver
25
Piping Application Binary Messages Through the
Reliable TLS Transport
JXTA Binary Message of arbitrary length

• Have no flowcontrol
• May arrive out of order
• May be dropped

Pipe
TLS Transport
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
26
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

27
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

28
Reliable TLS Transport (continued)

• Average round trip time (RTT) is used to
  calculate the retransmit time out (RTO), 1
  sec lt RTO lt 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

29
TLS Virtual Transport
Peer2
Peer1
M1 M2 Mn
M1 M2 Mn
Messages
P1 P2 Pn
Pipes
P1 P2 Pn
Endpoint
Endpoint
TLS Transport
TLS Transport
TLS Records
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.
30
(No Transcript)
31
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

32
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 CertificateVerif
y (Cert private key generated signature are
sent)
33
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.

34
End Security