gpgAuth is an authentication mechanism which uses Public/Private (cryptographic) keys (such as GnuPG, PGP) to authenticate users to a web-page/service.
The process works by the two-way exchange of Encrypted+Signed tokens between a user and the service.
The mechanism consists of a server-side process which:
- Stores the Public-Key(s) of the users - maintaining a map that correlates the key(s) to a user account.
- When a login request is initiated, the server process accepts a token of random data (a "nonce") - generated by the client and encrypted to the Public Key of the service/domain.
- Decrypt the token received from the client
- Generate a different nonce and encrypt it to the users Public Key, signed by the service/domain Public Key - and provided both to the client.
- Upon receiving the decrypted and signed result from the client, verify signature matches and compare the nonce against the original packet.
Some things to note regarding the server-side process:
- The server-side process is NOT a transport encryption mechanism akin to TLS/SSL. gpgAuth is an authentication mechanism for verifying the identity of users via cryptographic key verification and/or the web of trust.
- The server-side process does not have to be 'all or nothing', it can operate in other authentication environments.
- The server-side process is not specific to any particular programming language, web technology, operating system or web-server platform. gpgAuth has been implemented in environments such as: PHP, mod_python and Django.
- The server-side process is a process/protocol, not software - obviously you need logic to implement the process/protocol, but this can be achieved using just about anything which can communicate with the keyring software (such as GnuPG)
The client side process is responsible for performing the following:
- Storing the Public Keys associated with domains/web services
- Maintaining a map of keys to services/servers/domains
- Verifying the validity of the Public Keys [optional]
- Generating a nonce and encrypting it to the server/service Public Key [optional]
- Posting the data and initiating the login event [optional]
- Accept the decrypted nonce and verify the signature [optional]
- Accept the encrypted packet from the server/service, decrypt it and verify the decrypted data is properly encapsulated in the predefined wrapper
- Return a signed copy of the decrypted nonce to the server
Things of note regarding the client process:
- The steps marked optional are only necessary to perform symmetric authentication - to ensure to the client the server/service's identity.
- It is possible to perform this process of maintaining keys and exchanging tokens of encrypted/decrypted/signed data by hand (without client software)
- Software exists to automate this process
- After receiving an encrypted token, the client verifies the data is encapsulated by pre-formatted data to prevent the client from being tricked into decrypting and returning data that should not be returned to the server/service.