123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170 |
- Simple Peer-to-Peer Security
- ----------------------------
- SPTPS is a protocol that, like TLS, aims to provide a secure transport layer
- for applications. However, it is specifically aimed at peer-to-peer
- applications. Specifically, peers have each other's credentials beforehand,
- they need not negotiate certificates. Also, the security parameters of the
- application is also known beforehand, so they need not negotiate cipher suites.
- Only one cipher suite is available, and only one authentication method is used.
- This not only greatly simplifies the protocol, it also gets rid of an entire
- class of attacks and possible programming mistakes.
- SPTPS can be used both on top of reliable stream protocols such as TCP or on
- top of datagram protocols such as UDP.
- Stream record layer
- -------------------
- A record consists of these fields:
- - uint32_t seqno (network byte order)
- - uint16_t length (network byte order)
- - uint8_t type
- - opaque data[length]
- - opaque hmac[HMAC_SIZE] (HMAC over all preceding fields)
- Remarks:
- - The seqno field is never sent to the peer, but is included in the calculation
- of the HMAC.
- - At the start of the session, the HMAC field does not appear until after the
- SIGnature records have been exchanged.
- - After the authentication phase, the type and data fields are encrypted before
- the HMAC is calculated.
- Message type:
- - 0..127 represent application records. The meaning of the value is application
- specific.
- - 128 is a handshake record.
- - 129..255 are reserved and never to be used for application records.
- Datagram record layer
- ---------------------
- A record consists of these fields:
- - uint16_t length (network byte order)
- - uint32_t seqno (network byte order)
- - uint8_t type
- - opaque data[length]
- - opaque hmac[HMAC_SIZE] (HMAC over all preceding fields)
- Remarks:
- - The length field is never sent to the peer, but is included in the calculation
- of the HMAC.
- - The rest is the same as the stream record layer.
- Authentication protocol
- -----------------------
- The authentication consists of an exchange of Key EXchange, SIGnature and
- ACKnowledge messages, transmitted using type 128 records.
- Overview:
- Initiator Responder
- ---------------------
- KEX ->
- <- KEX
- SIG ->
- <- SIG
- ...encrypt and HMAC using session keys from now on...
- App ->
- <- App
- ...
- ...
- ...key renegotiation starts here...
- KEX ->
- <- KEX
- SIG ->
- <- SIG
- ACK ->
- <- ACK
- ...encrypt and HMAC using new session keys from now on...
- App ->
- <- App
- ...
- ...
- ---------------------
- Note that the responder does not need to wait before it receives the first KEX
- message, it can immediately send its own once it has accepted an incoming
- connection.
- Key EXchange message:
- - uint8_t kex_version (always 0 in this version of SPTPS)
- - opaque nonce[32] (random number)
- - opaque ecdh_key[ECDH_SIZE]
- SIGnature message:
- - opaque ecdsa_signature[ECDSA_SIZE]
- ACKnowledge message:
- - empty (only sent after key renegotiation)
- Remarks:
- - At the start, both peers generate a random nonce and an Elliptic Curve public
- key and send it to the other in the KEX message.
- - After receiving the other's KEX message, both KEX messages are concatenated
- (see below), and the result is signed using ECDSA. The result is sent to the
- other.
- - After receiving the other's SIG message, the signature is verified. If it is
- correct, the shared secret is calculated from the public keys exchanged in the
- KEX message using the Elliptic Curve Diffie-Helman algorithm.
- - The shared secret key is expanded using a PRF. Both nonces and the application
- specific label are also used as input for the PRF.
- - An ACK message is sent only when doing key renegotiation, and is sent using
- the old encryption keys.
- - The expanded key is used to key the encryption and HMAC algorithms.
- The signature is calculated over this string:
- - uint8_t initiator (0 = local peer, 1 = remote peer is initiator)
- - opaque remote_kex_message[1 + 32 + ECDH_SIZE]
- - opaque local_kex_message[1 + 32 + ECDH_SIZE]
- - opaque label[label_length]
- The PRF is calculated as follows:
- - A HMAC using SHA512 is used, the shared secret is used as the key.
- - For each block of 64 bytes, a HMAC is calculated. For block n: hmac[n] =
- HMAC_SHA512(hmac[n - 1] + seed)
- - For the first block (n = 1), hmac[0] is given by HMAC_SHA512(zeroes + seed),
- where zeroes is a block of 64 zero bytes.
- The seed is as follows:
- - const char[13] "key expansion"
- - opaque responder_nonce[32]
- - opaque initiator_nonce[32]
- - opaque label[label_length]
- The expanded key is used as follows:
- - opaque responder_cipher_key[CIPHER_KEYSIZE]
- - opaque responder_digest_key[DIGEST_KEYSIZE]
- - opaque initiator_cipher_key[CIPHER_KEYSIZE]
- - opaque initiator_digest_key[DIGEST_KEYSIZE]
- Where initiator_cipher_key is the key used by session initiator to encrypt
- messages sent to the responder.
- TODO:
- -----
- - Document format of ECDH public key, ECDSA signature
- - Document how CTR mode is used
- - Refer to TLS RFCs where appropriate
|