From Fedora Project Wiki
Revision history
- Changed to use an ordinary nested TLS session instead of a modified TLS
- Separated user's password (used to authenticate administrators) and key access passphrase (used to access a specific key); a single user may have different passphrases for different keys
- Links to data and protocol design added
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 passphrase for the key, and the key passphrase is encrypted with user's passphrase. When adding a new user, the key passphrase is decrypted using the key admin's passphrase, and encrypted using the new user's passphrase.
- Authenticates administrators by name and password, others by name, key name, and key passphrase
- The server does not accept any network connections
- 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 can physically access the certificate (and knows the key 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 in Koji
- Enforces round-robin scheduling between competing clients to avoid (unintentional or intentional) DOS by clients.
- Logs all requests.
The connection to the bridge consists of two separate "streams" (see FIXME protocol design), an "outer" stream that is readable by the bridge, and an "inner" stream that contains a nested TLS session between the client and server inaccessible to the bridge. This session is used to:
- encrypt passwords and passphrases when sending them to the signing server
- authenticate the request (to make sure the bridge cannot inject other data for signing or modify the requests)
Threats
Signing server compromise
- Countermeasures:
- No listening ports on signing server
- Bridge verifies correctness all protocol exchanges
- No direct access to koji or package repositories
- 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 passphrase, decrypt the key passphrase and use the key.
- Can copy encrypted key and encrypted passphrases elsewhere, and hope to obtain user's passphrases later.
- Can destroy/modify audit logs, but a copy of them is stored elsewhere.
- Cannot add another signer without being able to decrypt the key passphrase in the first place.
- Cannot publish packages using Fedora infrastructure without attacking the infrastructure as well
- Cannot return different data in response to a signature request because only the signature is expected in reply.
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 all requests are authenticated using an inner TLS session
- The signing server is authenticated using a certificate while establishing the inner TLS session
- Risks:
- Can deny service
- Cannot impersonate the signing server to clients without knowing the signing server's certificate key.
- Cannot get user's password without cracking the inner TLS session
- Cannot modify a request (e.g. substitute data to be signed, or grant access to a different user) without cracking inner TLS session or hash used to authenticate the request
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 passphrases 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 passphrases can be captured by an attacker
- Can sign a RPM without downloading it and manually checking it.