In the default configuration, IdP “sessions” maintaining cross-request state with the client are stored in the client in HTML Storage. The data must be integrity-protected, and by convention is kept confidental to avoid exposure of PII to malware that may infect a client. A component called a DataSealer uses symmetric encryption plus a message authentication code to “seal” the data.
How does the use-case relate to the software’s intended purpose?
Sessions are generally required for “expected” operation of the IdP, though they are technically optional. Session data may be stored server-side, at a cost in general system reliability (because clustered deployment requires a storage mechanism external to the IdP, introducing a wide range of failure modes).
Does the use case involve two or more independent software implementers being able to produce and consume ciphertext for the other or is it self-contained and lacking a requirement for interoperability?
The data is never intended to be consumed by any third party software or process and the specific format and mechanics used are undocumented and left as a detail of the implementation.
Are there standards defining/constraining which algorithms are usable for the use case?
No.
Is the output ephemeral or durable and for what expected lifetime?
The data is durable for the life of a session, which can vary quite a bit based on policy, though usually it is less than a day. In principle it could have an extended lifetime, but the implementation includes provisions for regularly updating the data so that it is continually “re-encrypted” under a current key.
Does the ciphertext provide sufficient information about the algorithm(s) used to allow for it to be consumed arbitrarily later?
Not presently, but since the format is internal to the software, it could in principle evolve to include this if it were needed.
What are the algorithms supported for this use case in current versions of the platform?
Currently, it only supports AES-GCM with key size depending on the configured key. In principle any authenticated encryption algorithm supported by the JCA could be used without major disruption or difficulty.
Does a process exist for rotating/changing the key(s) involved in the use case? If this is a standardized process, please reference it, and if not, please describe it. If there is an existing recommended policy regarding rotation frequency, please note that.
A command line tool and Java class are provided to maintain a set of files that track a default key and a variable size history of older keys, but it is a custom implementation. Is is assumed the files can be copied or accessed from a shared fle system by all servers in a cluster. A pluggable interface is used to allow alternative implementations. It is suggested that the key be changed daily or so depending on load, but in principle this is not strictly necessary as a random IV is used during each operation to prevent known ciphertext attacks.
Does a process exist for revoking/expiring the key(s) involved in the use case? If this is a standardized process, please reference it, and if not, please describe it.
Revoking or expiring a key can be accomplished by simply removing it from the source of keys used by the implementation at the cost of losing the ability to recover sessions encrypted by that particular key.
What degree of cryptographic agility exists in the particular use case?
Because the use case is purely internal to the implementation, it is possible to update the software unilaterally to alter or extend the set of supported algorithms. Changes to the encryption format would likely be required to account for the possibility of alternate algorithms and/or specifying them in the configuration, but this would be possible without coordination with third parties or major disruption to the software development lifecycle. However, changes to the format or algorithm set would create implications during rolling upgrades (if a node on one version was unable to create or consume data for or from another version) and this would have to be documented for specific releases. In practice, sessions would probably be invalidated in such cases as this would not be a major functional problem.
What is the impact of a compromise on the software’s purpose or a deployer’s data or infrastructure in functional (rather than assumed risk) terms?
Very significant/catastrophic.
As this use case implies session state is primarily stored client-side, a compromise would result in an attacker having the ability to easily forge session state, allowing the IdP to be subverted to issue authentication tokens for any user to any service in most configurations. A key compromise would be very easy to recover from (simply changing the key and removing the compromised one suffices) but a break in the AES-GCM algorithm or a vulnerability in the implementation would require a software update to the IdP (and an alternative algorithm or hybrid approach would need to exist).
Are there assumptions about how a deployer implements or uses the feature(s) that impact the answers above?
Some of the discussion is based on the default implementation of the key “strategy” supplied with the software that handles accessing keys. In principle, an alternative implementation built by a third party could impact some of the answers.