Provider of key material for pre-shared key (PSK) key exchange used in TLS-PSK cipher suites.
Overview of TLS-PSK
TLS-PSK is a set of TLS/SSL cipher suites which rely on a symmetric pre-shared key (PSK) to
secure the TLS/SSL connection and mutually authenticate its peers. These cipher suites may be
a more natural fit compared to conventional public key based cipher suites in some scenarios
where communication between peers is bootstrapped via a separate step (for example, a pairing
step) and requires both peers to authenticate each other. In such scenarios a symmetric key (PSK)
can be exchanged during the bootstrapping step, removing the need to generate and exchange public
key pairs and X.509 certificates.
When a TLS-PSK cipher suite is used, both peers have to use the same key for the TLS/SSL
handshake to succeed. Thus, both peers are implicitly authenticated by a successful handshake.
This removes the need to use a {@code TrustManager} in conjunction with this {@code KeyManager}.
Supporting multiple keys
A peer may have multiple keys to choose from. To help choose the right key, during the
handshake the server can provide a PSK identity hint to the client, and the client can
provide a PSK identity to the server. The contents of these two pieces of information
are specific to application-level protocols.
NOTE: Both the PSK identity hint and the PSK identity are transmitted in cleartext.
Moreover, these data are received and processed prior to peer having been authenticated. Thus,
they must not contain or leak key material or other sensitive information, and should be
treated (e.g., parsed) with caution, as untrusted data.
The high-level flow leading to peers choosing a key during TLS/SSL handshake is as follows:
- Server receives a handshake request from client.
- Server replies, optionally providing a PSK identity hint to client.
- Client chooses the key.
- Client provides a PSK identity of the chosen key to server.
- Server chooses the key.
In the flow above, either peer can signal that they do not have a suitable key, in which case
the the handshake will be aborted immediately. This may enable a network attacker who does not
know the key to learn which PSK identity hints or PSK identities are supported. If this is a
concern then a randomly generated key should be used in the scenario where no key is available.
This will lead to the handshake aborting later, due to key mismatch -- same as in the scenario
where a key is available -- making it appear to the attacker that all PSK identity hints and PSK
identities are supported.
Maximum sizes
The maximum supported sizes are as follows:
- 256 bytes for keys (see {@link #MAX_KEY_LENGTH_BYTES}),
- 128 bytes for PSK identity and PSK identity hint (in modified UTF-8 representation) (see
{@link #MAX_IDENTITY_LENGTH_BYTES} and {@link #MAX_IDENTITY_HINT_LENGTH_BYTES}).
Subclassing
Subclasses should normally provide their own implementation of {@code getKey} because the default
implementation returns no key, which aborts the handshake.
Known issues
The implementation of {@code ECDHE_PSK} cipher suites in API Level 21 contains a bug which breaks
compatibility with other implementations. {@code ECDHE_PSK} cipher suites are enabled by default
on platforms with API Level 21 when an {@code SSLContext} is initialized with a
{@code PskKeyManager}. A workaround is to disable {@code ECDHE_PSK} cipher suites on platforms
with API Level 21.
Example
The following example illustrates how to create an {@code SSLContext} which enables the use of
TLS-PSK in {@code SSLSocket}, {@code SSLServerSocket} and {@code SSLEngine} instances obtained
from it.
{@code
PskKeyManager pskKeyManager = ...;
SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(
new KeyManager[] {pskKeyManager},
new TrustManager[0], // No TrustManagers needed for TLS-PSK
null // Use the default source of entropy
);
SSLSocket sslSocket = (SSLSocket) sslContext.getSocketFactory().createSocket(...);
} | 