Skip to content
This repository has been archived by the owner on Jun 12, 2024. It is now read-only.

Key Log Server

Jump to bottom
somogyi-google edited this page Dec 16, 2014 · 2 revisions

Design

The key server has two operations, insert and query. The log server has two operations as well, one where it adds new entries to the log, and another one when it generates audit paths in the log.

This section of the document doesn't describe the types of checks that a client is likely to perform on a public key in addition to the audit paths, nor the way for the user to transfer secret keys across devices.

Flow

  • The flow with the interactions on the key/log server is described below: Diagram describing the key server flow.

    Enrollment

  1. User authenticates with Identity Provider and requests an id_token.

    This allows the key server to host the keys of different service providers, and delegate the authority to authenticate them to the Identity Provider itself.

  2. Identity Provider gives the user an id_token for the specified id.

    The id_token is a signed blob that uniquely identifies the user at a given point in time. The id_token is only valid for the key server and for nothing else.

  3. The user sends the id_token and the public key to the Key DB.

The user sends the id_token together with the key to the key server.

  1. The Key DB asks the Identity Provider for the certificates used to sign the id_token.

    The key server needs to verify that the id_token was issued by the correct identity provider, so it performs discovery itself and asks the identity provider for the public key used to sign the id_token.

  2. The Identity Provider returns the certificates used to sign the id_token.

    The identity provider produces the public keys that can be used to independently verify the validity of the id_token.

  3. The Key DB logs the id<->key mapping in the log and stores the audit path.

    They key server stores the mapping between email address and key, and stores it in the log server. The log server generates an audit path and sends it back to the key database.

    Key Lookup

  4. The user queries the Key DB for an email address.

    In order for a user to find a key for a given user, it asks the key server for the email address of the recipient.

  5. The Key DB returns the key for that email address and its audit path.

    The key server returns the key it has stored for that email address, and the audit path that the log sent back (and possibly Monitors' signatures).

  6. The user sends the message to the receiver. The user can now send a message encrypted to the key and include in the message the log's audit path and the key assertions made at that time.

    Verification

  7. The receiver verifies the keys are consistent with the log. The receiver asks the log for the audit path for the sender's signing key, and possibly a signature by a monitor.

  8. The log provides audit path to show the key is up to date. The log provides a new audit path or presence for the keys from the tip sent by the user, as well as the other assertions requested by the user.

    Monitoring

  9. The monitors ensure that the mappings in the log are valid. The monitors check that all the identity assertions provided in the log are valid. If an identity provider is also a monitor, the identity provider would confirm that it issued all the keys used to authenticate its users, and if it finds any inconsistencies, it would revoke them.

Threat Model

Different components of the system trust and interact with other components in different ways. This section enumerates the contracts and expectations from each side, the problems that a failure in each side could cause, and the mitigations in place to limit such problems.

Enrollment

During enrollment the components that come into play are:

  • User
  • Identity Provider
  • Key Server
  • Log

The User / Identity Provider have the following trust relationships during enrollment:

  • User must authenticate with the Identity Provider.
    • First, the User needs to ensure it sent the authentication credentials to the right Identity Provider. Malware, weak authentication credentials, phishing, weak transport-layer security, etc.. are known to be problems in this situations.
    • Second, the Identity Provider must authenticate the user. Most security vulnerabilities like XSS, CSRF, Auth bypass and so on, could potentially compromise this step of the flow.
  • The Identity Provider must provide a signed id_token to the User.
    • The id_token is a signed blob that contains an assertion about the user identity. If the signature scheme is weak, or the keys are compromised, it could allow an attacker to forge the id_token and bypass the authentication step.
    • By definition, id_token is scoped to the service that requested it. If the Identity Provider mistakenly provided an id_token for the Key Server to a third party, then it would allow such third party to impersonate the user to the Key Server.
    • Same as with the authentication credentials, the id_token must be securely transmitted back to the user, failure to do so could allow a third party to impersonate the user.

Note that the nonce parameter in the OpenID Connect protocol could be used to transmit the fingerprint of the key being registered (and so, tie a given id_token to a fingerprint). However, the value of such nonce isn't defined to be parseable as far as OpenID Connect is concerned.

The risks introduced by a compromised User or a compromised or malicious Identity Provider are generally mitigated by the audit trail provided by the Log Server, as they help the User find out of a compromise, and take actions to revert it (additionally, since the audit trail is public, it sheds some light on the security of different identity providers).

The Identity Provider can as well, by means of the Log Server, audit if the Key Server ever issues a key for one of it's users with an invalid id_token. This also has the side effect, that a user that wishes to join the network, but is concerned of an Identity Provider misrepresenting his identity, to simply run it's own Identity Provider, and audit the log for forgery.

The User / Key Server have the following trust relationships during enrollment:

  • The User must send the id_token and the key to the Key Server.
    • The id_token serves as an authentication credential. If the user sends the id_token to the wrong location, then someone else could impersonate the user and register a different key on their behalf.
    • If the user sends a weak or invalid public key, it would allow an adversary to decrypt the otherwise encrypted data.
    • If the id_token is not transmitted securely, or is leaked in any way, it would allow an adversary to steal the token.
    • The Key Server needs to verify the id_token is signed correctly by the legitimate Identity Provider, that the token isn't expired, that it was recently minted, and that it's not reused as well that it is scoped to the right Key Server (audience).

The Key Server needs to verify that the id_token is valid, to do so, it needs to independently fetch the public keys used to sign the assertion from the right Identity Provider. As such, the Key Server needs to perform discovery to validate that the issuer specified in the id_token is the legitimate Identity Provider.

Same as with the Identity Provider, the risks introduced by a compromised Key Server are generally mitigated by the audit trail provided by the Log Server, as they help the User find out of a compromise, and take actions to revert it.

The Key Server / Identity Provider have the following trust relationships during enrollment:

  • The Key Server finds the keys used to sign the id_token.
    • If the Key Server trusts the issuer included in the id_token instead of performing discovery by itself (or otherwise, verifying the authority of such Identity Provider), an attacker could cheat the Key Server into accepting a forged id_token.
  • The Identity Provider responds with the key (specified by the key id in the id_token).
    • If the Identity Provider is connected insecurely to the Key Server, then an attacker performing a Man in the Middle attack could return an invalid key to the Key Server.
    • If a specific secret key was stolen, the Identity Provider should be careful to invalidate it so that it can't be used to impersonate other users.

One of the important properties of the system is that the Key Server must independently verify that the id_token provided is, in fact, a valid authentication token provided by the legitimate owner of the claimed email address. Any mistake will be permanently and publicly logged, and is used to allow the User to keep track of it's key's security.

The Key Server / Log Server have the following trust relationships during enrollment:

  • The Key Server will send a key/email pair to the Log Server.
    • The Log Server stores a non-deletable record of the fact the Key Server associated a given key with a given email address. If the Key Server adds an invalid record (with an invalid id_token for example) it would be permanently stored in the log.
    • If the Key Server doesn't throttle the number of insertions into the log, then the log could potentially be overwhelmed by the traffic, and stop responding to legitimate requests.
  • The Log Server will provide back to the Key Server the key's audit path.
    • If the Log Server's generates an invalid audit path, then it would forbid all users that have ever seen the invalid audit path from being able to use the service, and monitors would detect the inconsistency and assume malicious intent from the Log Server.

Key Lookup

During key lookup the components that come into play are:

  • Sender
  • Key Server
  • Recipient

The Sender / Key Server have the following trust relationships during key lookup:

  • The Sender connects to the Key Server to query for the key of a given email.
    • If the Sender doesn't connect securely to the Key Server, then the identity of the recipient could be leaked.
  • The Key Server returns to the Sender the key and audit path for the given email.
    • If the Sender doesn't check the validity of the key (the audit path in the log, and the linked key provided by the user), then the sender could be deceived into encrypting to a public key that is not present in the log server and that the user wouldn't notice.
    • If the Key Server sends an audit path of the log that is only visible to a subset of users, then the client will find out via gossip, or by the lack of Monitor's signatures.

Overall, the Key Server just acts as simple storage for the information processed by the Log Server, and such, the only checks the Sender has to make are making sure it's not leaking the identity of the recipient to the network, and that the key returned by the Key Server is present in the Log Server before encrypting the data to that key.

The Sender / Recipient have the following trust relationships:

  • The Sender (via his EMail provider) sends the encrypted message to the Receiver.
    • If the Sender's or the Recipient's EMail provider don't properly secure the message metadata (recipient, sender), then the identities of the recipients might leak.
    • If the Sender encrypts the message to other recipients, then the Sender is responsible to ensure the other recipients keys won't compromise the message's security.
    • If the Receiver's EMail provider doesn't employ anti-abuse/DoS/SPAM measures to protect it's users from abuse, then the user could be overwhelmed by the number of encrypted messages, and not be able to read valid ones.
    • If the Receiver doesn't check that the key assertions and the audit path in the log is consistent with the cached view of the log it has, then the Receiver wouldn't be able to notice an invalid log.

The verifications made by the Receiver are done in order to detect inconsistencies in the view presented by the Log Server presented to the Sender and the Receiver (and so, discourage the Log Server from doing so, as it would get caught).

To detect attacks in which a Log Server gives different versions of the log to different clients, the Receiver would have to diversify the places where it receives audit paths on top of the key server.

To prevent that, the Users gossip (via their messages and key lookups and potentially via SSL connections to normal HTTPS servers) the signed heads of the Log Server (and potentially the SSL Certificate Transparency log). This means that in order for a user to be attacked, all emails and other OpenPGP messages would have to be Man-in-the-Middled (including SSL services). In such situation it would be very risky for a Log Server to cheat it's users if it's concerned of being caught.

Verification

During verification the components that come into play are:

  • Receiver
  • Log Server

The Receiver / Log Server have the following trust relationship:

  • The Receiver queries the Log Server to get the signing key of the sender, and verify the claims made by the Sender.
    • This will include querying for the keys the message was encrypted to, to ensure the assertions were valid, and verifying the public key of the user is actually in the key server.
    • This might also include the appropriate Monitor signatures, which the client would then verify if it so requires.
    • If the Receiver doesn't use a secure channel to communicate to the Log Server, the Receiver would leak the identity of the senders and receivers of the message it's processing to the network.

This step is also useful for the Sender (even if he doesn't see it happening) because if the Key Server provides an outdated or revoked key to the Sender, then the Recipient would detect it (although, it would assume that he is being given a key that no other user has).

The Log Server can provide signatures from a group of monitors that assert that a given section of the log was audited. The client can decide to only trust keys in the log, if the log has been audited by a specific Monitor (for example, if an Identity Provider is also a Monitor, it could make sense that a client only accepts keys from a certain Identity Provider only if the Monitor has checked the specific section of the log).

Monitoring

The final component of the Key/Log Server is the Monitors. During monitoring, the components that come into play are:

  • Log Server
  • Monitor

The Log Server / Monitoring have the following trust relationships:

  • The Monitor fetches a delta from the last view it had on the Log.
    • If the Log Server provides a fake delta to the Monitor, it's signature wouldn't match what the Log Server will provide to clients, so it won't be able to use it.
    • If the Monitor has an outage, the Log Server wouldn't be able to get a signature from it, which would make clients that expect signatures from Monitors not to work.

Overall, Monitors don't always have to be online, but there is an expectation that if a Monitor is added to a client, it will have some minimum up-time and audit-ability requirements.

Clone this wiki locally