User:Mitr

Functionality

• Allow generating GPG signatures without possession of the key and passphrase
  • A low-level "perform an RSA/DSA operation with this key" operation is not provided to avoid chosen-plaintext attacks.
  • This includes RPM signatures.
• User/key management:
  • Server admin can create/delete keys and designate key admins
  • Key admin can add/remove signers for the managed key
• ? Is an integrated backup facility necessary, or will a complete system backup be performed?

Design

Three major components:

Signing server

A separate machine (? virtualized host?) that stores the keys and passphrases.

• Passphrase is randomly generated, never changed, and not stored on disk directly.
• Each user with access to the key has their own password, and the key passphrase is encrypted with user's password. When adding a new user, the key passphrase is decrypted using the key admin's password, and encrypted using the new user's password.
• The server does not accept any network connections
• Authenticates users by name and password
• Automatically connects to the bridge over the network (other network access is firewalled) and waits for commands.
  • Non-network connection (USB/serial) does not provide enough infrastructure (packeting, checksumming, retransmissions, debugging tools) that I'd rather not reimplement now; this can be replaced later if necessary.
  • The connection uses TLS, both sides of the connection authenticate each other using a

certificate (configured to accept only one certificate)

• Logs all requests, sends a copy of the log to another computer.

Client

A computer operated and trusted by the signer, submits signature requests to the bridge (connects using TLS).

Bridge

Accepts connections from clients (from anywhere on the Internet), verifies them and passes them to the signing server.

• Authenticates users by Fedora certificate, verifies they are in a "signing server users" group. Username/password is not accepted to make sure the client physically posesses the certificate (and knows the passphrase, which is verified by the signing server.)
• Verifies the signing server requests before passing them to the signing server
• If the client requests it, the bridge injects RPM data for signing from Koji into the request forwarded to the signing server and stores the generated RPM signatures back to Koji
• Enforces round-robin scheduling between competing clients to avoid (unintentional or intentional) DOS by clients.
• Logs all requests.

When the client connects to the signing server through the bridge, they establish (e.g. using a DH key exchange) secret keys unknown to the bridge. These keys are used to:

• encrypt the personal password when sending it to the signing server
• authenticate the request (to make sure the bridge cannot inject other data for signing)

The signing server's certificate is used to authenticate the key exchange.

(Designing a security protocol is risky, but we can very likely just drop most of negotiation from TLS and selectively enable/disable encryption for some parts of the data, keeping the rest intact.)

Threats

Signing server compromise

• Countermeasures:
  • No listening ports on signing server
  • Bridge verifies correctness all protocol exchanges
  • The signing server disconnects after responding to each request and launches a new process to respond to any following request
  • Encrypted swap
• Risks:
  • Can wait until a legitimate signer attempts to encrypt something, the capture user's password, decrypt the passphrase and use the key.
  • Can copy encrypted key and encrypted passphrases elsewhere, and hope to obtain user's passwords later.
  • Can destroy/modify audit logs, but a copy of them is stored elsewhere.
  • Cannot add another signer without being able to decrypt the passphrase in the first place.

Side channel attacks on the signing server

• Countermeasures:
  • No other users on the signing server. Ideally the signing server would be a separate physical computer.
• Risks:
  • Can observe the key as it is used for signing.

Attacks on the network connection between the bridge and signing server

• Countermeasures:
  • The connection uses TLS, both sides are authenticated using a certificate.
• Risks:
  • Can deny service

Modification of the data stream is discussed below.

Attacks on the bridge

• Countermeasures:
  • Connections from the signing server and clients are using TLS, authenticated using certificates
  • Passphrase is encrypted and signing requests are authenticated using ephemeral keys
  • The signing server is authenticated using a certificate while generating the ephemeral keys
• Risks:
  • Can deny service
  • Cannot impersonate the signing server to clients without knowing the signing server's certificate.
  • Cannot get user's password without cracking the key exchange or cipher
  • Cannot substitute data to be signed without cracking the key exchange or authentication protocol

Attacks on the network connection between the client and the bridge

See Above.

Attacks on the client

• Countermeasures:
  • Client has never seen the key nor passphrase
  • Access can be revoked
  • User's password can be changed
  • RPM signing requests specify some kind of checksum of the RPM / it's header
  • ? Would it make sense to require a signing request from two different users before acting on it?
• Risks:
  • Can intentionally sign malicious data
  • User's certificate and password can be captured by an attacker
  • Can sign a RPM without downloading it and manually checking it.