Add support for server-side ephemeral keys

[petrdvorak]

Currently, we use an ECIES algorithm with fixed keys (master server public key, device public key) that are stored on the mobile device and client-side ephemeral keys. This is good, but we could also add support for the server-side ephemeral keys (let's call them "temporary keys" here).

Gist

Temporary Public Key Exchange

• The client asks the server for an ephemeral key, sending a random nonce as a "request ID".
• The server generates a temporary keypair and it responds to the client with the request ID, temporary public key and signature of both public key and request ID computed with a master secret private key (or device private key).
• The client verifies that the request ID matches the expected value and then verifies the signature (to prove authenticity of the public key).

=> Client now has a new one-time public key

Temporary Key Pair Storage on Server-Side

Server (probably PA Server) should store temporary keys in a separate table, such as pa_temporary_keypair. Each record should be one-time-only (when used, it should invalidate) and should have short expiration (to allow the cleanup).

Encrypting Request and Response

The encryption/decryption works the same way as for our current ECIES. The temporary key should be invalidated once the encrypt/decrypt cycle is completed.

[romanstrobl]

I suggest we look at ECDHE_ECDSA in RFC 4492: https://tools.ietf.org/html/rfc4492, the TLS 1.2 specification defines a similar protocol for authentication of a public key.

[romanstrobl]

In particular, section 5.4 defines the data being signed by ECDSA:

[petrdvorak]

To add one more comment to this topic. The improvement will provide us with:

• Forward secrecy in use cases where we currently do not have it.
• Improved compliance with requirements on short key lifetime and limited key reuse.
• Improved compliance with requirements on one-purpose-specific keys.
• Even more improved protection from replay attacks (as the key itself will be one-time).