The TGMA architecture offers the following benefits:

• A user does not need to provide a password for sign-on.
• No information, such as a password, is sent between communicating parties that might be copied by an attacker and used to sign-on as the user (e.g., via keystroke logging or a network sniffer).^[9] It is not even necessary for the user to provide his plaintext password to a server at enrollment time.
• TGMA account information maintained on a server does not contain passwords or information that is derived from text. Long, random bit strings are used as keys, so each instance of account information will be different from all others and obtaining one account instance does not help an attacker access any other systems. The account information is not of any direct use by an attacker as it essentially functions as a public key and would be of dubious benefit to a fake validator. Because each system interface configured into a validator is associated with a particular server and reserved port, and this information cannot be directly modified by the user or software on the validator, it would be difficult for an attacker to mount a phony server that might be used to trick a user.
• The service provider is authenticated (server and service names) to prevent a phishing attack or accidentally revealing authentication-related information that might be reused by an attacker.
• Strong encryption and authentication is always used, rendering attacks based on guessing impractical.
• In a standalone mode of operation, a user need not have Internet access at sign-on time (such as when logging in at a desktop or unlocking a door).
• To increase the level of security in response to improvements in computation speed, TGMA's M-AUTH algorithm can be slowed arbitrarily, such as by iterating a hash function (see: PBKDF2 - Password-Based Key Derivation Function, bcrypt, and scrypt). TGMA can be strengthened as necessary simply by selecting different cryptographic algorithms or parameters at run time, or in the worst case, by updating the validator software. This is important in the event that a weakness is found in a function used for M-AUTH. In password-based methods of authentication, a hash of the (usually salted) password is stored^[1] and if a weakness in the hash function is discovered, all users must reset their passwords so that they can be processed by the replacement algorithm.
• Since each instance of a user's validator can be uniquely identified, they can be treated identically or distinctly. Sharing account access with others remains possible (e.g., by lending a device), but account passwords need not be shared and access to any account can be limited to a particular validator instance.^[2] Different users can sign-on to the same account as the same username (e.g., guest), but each will have a unique TGMA account at the server. Each sign-on instance can be correlated with that TGMA account, and an individual TGMA account can be disabled or deleted without affecting the others.
• Besides traditional kinds of system interfaces, such as web site sign on, and workstation or laptop sign on and screen locking, a system interface can also be a controller for a device. These include such network computer system components as switches, routers, and printers, as well as industrial machinery.^[3] Comprising physical objects with network connectivity and known as the Internet of Things (IoT),^[4] or the Physical Web, a wide array of network-accessible "smart" devices rely upon authentication: watches, home automation (thermostats, smoke detectors, fridges, furnaces, light bulbs, cameras, garage door openers, entry doors, televisions), medical devices (pacemakers), elevators, vehicles, and so on. Some of these devices have a serious need for authentication,^[6] but most have limited or no capability for password entry.^[5]

  For example, a user might carry a key fob that uniquely identifies him (e.g., via near field communication) to his car's authentication module as he approaches the vehicle. He then uses the validator app on his smart phone, which has been configured for his identity and the vehicle, and Wi-Fi or cellular network communication with the vehicle to prove his authorization to operate the car. Theft of the key fob or interception of any of the wireless communication can not yield authorization to an attacker. If the app and/or phone employ password protection, as they should, theft of the smart phone does not help an attacker. This might also be done without a fob if the distance between the authentication module and validator can be measured with sufficient accuracy.

  Recall that the M-AUTH protocol employed by TGMA is practically immune to communication eavesdropping, whether over LAN, cell, or Wi-Fi networks (even if communication is not encrypted, e.g. by WPA or WPA2), so an attacker cannot re-actuate a device by replaying or modifying captured network traffic, or by pretending to be a legitimate system interface.

  Because a validator is independent of the system interface being accessed, a general-purpose validator implementation can be used to access a large set of system interfaces, even these non-traditional ones. Instead of each product vendor creating its own app for accessing its products, a single, generic validator app can give a user convenient access to many products (much like a person carries a keychain to hold keys for many locks).

• The method is comparatively "accessibility friendly" in that all interactions can be made simple to perform using scrolling and pointing actions.
• A special-purpose device, such as a dongle or security token required by some two-factor authentication methods, is not used.
• By providing an optional administrative callback in the final phase of sign-on, flexible real-time administrative control and monitoring is possible. This is a feature that could possibly be added to other authentication protocols, but it is part of the original TGMA architecture rather than a retrofit or add-on.
• Unlike some other schemes that use a mobile device for authentication, neither cellular service nor Wi-Fi service is essential. Should cellular data transmission be used there may be a charge, but only a small amount of data transmission is used by the protocol. A user does not need to register her mobile telephone number to use TGMA, and text messages, which may incur a cost, are not required by TGMA.^[7]
• A feature that comes easily for the TGMA architecture, but is of limited applicability, is to require N validators (most commonly, two) to simultaneously approve sign on (called the two-man rule). A majority voting scheme could also be used. This might be used to increase the level of security or ensure that a more senior person permits another to sign on.
• Another feature that falls out of the architecture is a capability for a group of two or more users that authenticate through the same system interface to communicate securely. The network demultiplexor can act as a key server, distributing session encryption keys to clients. As the group members have performed mutual authentication with the system interface, the membership of the group is managed implicitly. For example, suppose we want to dynamically create encrypted peer-to-peer chat connections. Alice signs on to the chat service as alice with operation listen, which indicates that she is willing to accept chat requests. An encryption key is returned to Alice and a record of the transaction (that includes the encryption key) is stored by the system interface. Bob signs on to the chat service as bob with operation call alice, requesting a connection to Alice. An encryption key that Bob can use to talk to alice is returned. Encrypted peer-to-peer connections can now be established between pairs of parties or via an intermediary server.

Three general use cases for TGMA are presented here. To simplify the presentation, opportunities for various features and improvements are omitted.

1. Sam, who has Internet access, signs-on
   
   1. Sam is prompted by the TGMA web page at server s1.example.com to enter or select a username.
   2. Sam responds by typing his username, sam.
   3. The server looks up username sam and confirms that it corresponds to a TGMA-enabled account.
   4. The server displays a passcode.
   5. The server waits, up to a configured maximum length of time, for a validator for Sam's account to establish a connection. The time limit is at the discretion of the server.
   6. Running his validator, Sam looks for s1.example.com from the list of system interfaces known to his validator. If it is not found, or if Sam does not select it, the sign-on window will expire, sign-on will fail, and the system interface will notify the user. If the server is found, the validator establishes a connection to the system interface and the M-AUTH protocol proceeds.
   7. The system interface and validator execute a secure M-AUTH protocol:
      • If the validator detects a problem with M-AUTH, it instructs the user not to sign-on, and the procedure terminates.
      • If the system interface detects a problem with M-AUTH, user sign-on fails and the procedure terminates. The system interface may perform arbitrary validation tests based on the username and authentication context.
      • The server sends authentication context to the sign-on validator and awaits a response, which the sign-on validator must send within a configurable acknowledgement window. The validator can display the authentication context or perform arbitrary validation tests on it, giving Sam an opportunity to cancel sign-on through his validator.
      • Sam enters the passcode into his validator.
      • If both sides are satisfied with the outcome of M-AUTH, the validator is convinced that it is communicating with s1.example.com and the server is convinced it is communicating with an authentic validator for Sam and that it is Sam that is signing on.
      • If the validator aborts sign-on, it sends a negative response to the server or closes the connection, and the procedure terminates with the user unauthenticated
      • In this case, no sign-on approver has been registered with the system interface.
      • If the server detects a problem or it does not receive a response within the acknowledgement window, sign-on fails, the system interface informs the user, and the procedure terminates with the user unauthenticated.
2. Sam signs-on and a sign-on approver is invoked

   This use case is like the previous one except that a sign-on approver is invoked by the system interface as the last step. The pre-configured sign-on approver is invoked (perhaps by HTTP over SSL/TLS, but not necessarily), with the system interface identifying itself. In this example, a web-service on a corporate web server is called to record that Sam has signed on and return an indication that sign-on may proceed.

3. Sam signs on to his desktop but his validator does not have Internet access
   

   In this standalone mode of operation:

   1. Sam selects the icon that corresponds to his account from those presented on the screen. The desktop confirms that the account is TGMA-enabled.
   2. The desktop displays a QR barcode and passcode.
   3. Sam selects his desktop from his validator's list of known system interfaces and scans the QR barcode using his validator device's digital camera.
   4. The validator decodes and validates the QR barcode, extracts and displays parameters, and asks for Sam to confirm that sign-on may proceed and provide the passcode.
   5. If Sam approves, the validator generates and displays a one-time password; e.g., a base-64 encoded character string computed by signing a random string included in the QR barcode or using HOTP (RFC 4226) or TOTP (RFC 6238).^[10]
   6. Sam types the one-time password into the system interface. If the system interface cannot validate the one-time password, sign-on fails.
   7. A sign-on approver that was previously registered is called by the system interface. The approver returns an error message, indicating that Sam is not allowed access to the desktop because it is after 7pm. Authentication at the desktop system interface fails.

In the following use case, Bob has a device with which he wants to interact securely through custom application software that includes validator functionality. Bob must first authenticate himself before interacting with the device (say, a smart thermostat). The "device" could also be software, such as a server, that requires user authentication and might use a special validator as a "remote control". A typical approach to this would be to run a simple web server on the device, perhaps accessed using a standard web browser over SSL/TLS, with a username and password required.

• Bob begins by initiating authentication on the device, selecting a particular username or using a default username. (1) (It may be unnecessary for Bob to choose an identity at this point; he could do so via through his validator in a later step.) The validation interval begins.
• The device displays a new passcode, connects to a previously configured authentication server (specified in the device's configuration), and conducts mutual authentication. This identifies the device (and possibly Bob) to the server and vice versa. The server is given the passcode and waits for Bob's validator to connect. (2)
• Bob proceeds by selecting his account on the device from the list presented by his validator and entering the passcode. (3)
• Bob's validator connects to the server associated with the selected account (according to validator configuration) and mutual authentication is performed. (4) This proves Bob's identity to the server and the legitimacy of the server to Bob.
• The server completes its role in the authentication procedure after ensuring that the validator and device share an ephemeral key. (2' and 4') This step must be finished within the validation interval.
• Bob's identity has been proven to the device and vice versa. His validator can connect to the device using a suitable protocol, and communication between them can be encrypted and authenticated using the shared encryption key. (5) SSL/TLS is not used.

Although the validator and the device have not mutually authenticated directly, they have both mutually authenticated with the server. If either the validator or device did not do this successfully in this transaction, or if an attacker is actively participating, message validation will fail (with very high probability).

Note that the account information used by the server to authenticate the device would normally be different from that used by the server to authenticate Bob's validator.

Since it appears that the procedure can be simplified if the server component can be integrated with the device, why does the validator not mutually authenticate with the device in this configuration? We are assuming in this use case that for practical reasons (e.g., limited memory, better configurability, simplified implementation, additional security) the device relies on the server to store and manage account information for the device's users. This reduces the amount of software on the device and data storage needs. More importantly, account information stored on the server can be shared by all of Bob's validators, administered remotely, and so on.

Is it safe to delegate the server component to a third party? What are the implications if the server component is compromised by an attacker? In particular, could a malicious server connect to the device as a legitimate validator? One preventative measure is for both the device and validator to send only part of the passcode to the server, or for them to send the same one-way hash of the passcode, so that only they know the complete passcode. The connection from the (purported) validator to the device must present the original passcode. In this way the server cannot use its copy of the shared key to impersonate the validator to control the device.

In an architecture where the device cannot display a passcode, it does not send a passcode to the server. Instead, the server provides Bob with a passcode after Step (2). In some contexts, such as when the device is non-shareable, this can be taken a step further by not requiring Bob to physically activate the device (say, a remote webcam) but instead activates the device by sending it a message.

To give another example, consider a use case where Bob wants to conduct some banking using an app on his smart phone. The app has been issued by Bob's bank and is preconfigured to authenticate by connecting to its server. Bob has a validator installed on his tablet (or laptop or desktop) that has been provisioned to mutually authenticate with the bank.

• Bob starts the app on his phone. It asks him to sign on and displays a passcode.
• Bob selects his bank identity on the validator (e.g., "Bob signing on to BigBank via his phone") and enters the passcode.
• Bob's phone mutually authenticates with the bank's authentication server, as does Bob's validator.
• Bob's validator exchanges encrypted messages with the app, which proves to both the app and the validator that all is well. Since the app is satisfied that Bob has proved his identity, he is signed on.

In a similar use case, Bob needs to interact with a Wi-Fi capable smart device in his home. The device has been configured to authenticate by connecting to a server - the server might run on Bob's computer, be provided by the device's vendor, or run on a provider's cloud-based service.

• Bob starts a controller app for the device on his tablet. It asks him to sign on and displays a passcode.
• Bob selects his device identity on the validator (e.g., "Bob signing on to Device via his tablet") and enters the passcode.
• Bob's phone mutually authenticates with the device's authentication server, as does Bob's validator.
• Bob's validator exchanges encrypted messages with the app, which proves to both the app and the validator that all is well. Since the app is satisfied that Bob has proved his identity, he is signed on.

Continued in Part 6.