[Skip to Content]
homehome
contact CTIcontact
feedrss
gpgAuth : Introduction

12/20/2010 *** FireGPG has been discontinued; so we are working on implementing a new browser solution; we are taking this oppotunity to change some of the structure, as, FireGPG was the only gpgAuth client I am aware of, we won't be breaking the protocol for anyone. A client supporting gpgAuth v1.3.0 is almost ready. ***

gpgAuth is an authentication mechanism which uses Public/Private (cryptographic) keys (such as GnuPG, PGP) to authenticate users to a web-page/web-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.
 
INDEX
2 : Server Implementations >>
 
mod_python  gpgAuth Enabled