Time-Gated Mutual Authentication
System Architecture: Part 3

DRAFT (15-November-2016)

Distributed Systems Software
Victoria, BC

Part 3

Goals of TGMA

Every authentication system makes trade-offs between security and practicality. TGMA aims to maximize[10] both characteristics by combining strong cryptographic methods with separate communication channels. A successful attacker must breach multiple components of the system simultaneously.

TGMA is intended to meet the following requirements:

A fundamental requirement of the TGMA design is to maintain security while assuming that an attacker:

It is assumed that best security practices are observed in implementations and by system administrators on servers, and that users take reasonable precautions. The security of a given account depends on protection of the software on a secondary computer against unauthorized access or theft. General attacks against a server, such as denial of service attacks (DoS), are outside of the scope of the protocol but may be addressed by common techniques (e.g., inserting delays between sign-on attempts, locking out accounts after unsuccessful sign-on attempts, using appropriate firewall rules). A denial of service attack may prevent legitimate users from authenticating.

TGMA is not intended to supplant every authentication method in all cases. In situations where a user has already been authenticated, single sign-on methods can be used to provide secure sign-on with no additional user interaction (e.g., sshd(8)). Also, TGMA is not designed for non-interactive use cases. When it is warranted, however, it can be be combined with other types of authentication to improve security.

Architectural Components


The following concepts referenced in this paper are now more fully defined:

A TGMA system comprises the following active components:

Continued in Part 4.


  1. For the vast majority of users, the requirement for a different secure password for each account means that either passwords must be written on paper and searched for when needed, or password management software used. Entering a secure password, for most people, will always be slower and more error prone than typing a weak password from memory.
  2. See: pseudonymity, "PayPal Wants You to Inject Your Username and Eat Your Password".
  3. Refer to The God Login and Your Password is Too Damn Short for helpful design tips.
  4. Perhaps more commonly now, a mobile app is used to manage a device: The Future of Car Keys? Smartphone Apps, Maybe, 75 Percent of Bluetooth Smart Locks Can Be Hacked
  5. The idea of moving much of the validator's functionality to a secure system managed by or on behalf of the user may be appealing. By adding a level of indirection to the architecture, the validator would mutually authenticate with the secure system, and the secure system would perform authentication with a system interface. This would offer some advantages, most importantly to enable a managed authentication service, but it would introduce additional moving parts and complexity. It is useful for development and testing, however, since it allows a browser-based GUI that approximates a validator interface to be rapidly developed. An HTML menu or even individual links (bookmarks) can be used to trigger a particular validation operation, with the actual validation logic being executed elsewhere.

    If only for development and testing purposes, the system interface's side of the protocol can be run as a separate server rather than calling the TGMA library code directly. For instance, a PAM authentication module can make an HTTP request to a CGI program that implements TGMA server functionality (such as dacs_auth_tgma). The system interface blocks until the protocol completes, the CGI program indicates the outcome, and the system interface resumes. This makes it easy for any system interface capable of making an HTTP request to work with TGMA.

  6. It is common and expected practice for users to password-protect general access to their mobile devices (or use a biometric method) and to similarly control access to their important mobile device apps, such as banking or email apps.
  7. Apart from their use as a sign-on validator or password manager, because of the value of cell phones and tablets, and the personal and financial information they typically contain, these devices will always be attractive targets for theft. Possible methods of strengthening the protocol or validator implementation are being investigated that would make it even more difficult to use a stolen validator or obtain useful information from it. Notably, the repercussions from copying another person's password, by whatever means, are likely to be much less severe than those from stealing that person's mobile device.
  8. This might also be invoked upon unsuccessful authentication for notification purposes.
  9. This capability could be present in just about any authentication system. While it is not a core feature of TGMA, because it is particularly useful for TGMA it is a documented component in the initial design.
  10. We are going to say that attacks against TGMA are "difficult" rather than "impossible" because there is always the possibility of an implementation, configuration, or hardware error, a new weakness in a cryptographic method, a previously unknown kind of attack, and so on. There is a theoretical possibility of successful attack on nearly every system. That said, careful use of cryptographic digests, keyed-hash message authentication codes, cryptographic ciphers, key-agreement protocols, and so on with large key sizes are capable of making many attacks infeasible and reducing the number of attack vectors.
  11. Consider the common case where a student wants to sign on to a workstation in a classroom. After entering her username, she her validator must be able to communicate with the workstation. If she does not have Wi-Fi access to the workstation, her validator must use her cellular service to establish a connection for TGMA. Since the workstation is not directly reachable from the Internet but is instead on a private intranet, and behind a firewall, software must be in place to accept the connection and relay it to her workstation over the intranet.