Time-Gated Mutual Authentication
System Architecture: Part 5

DRAFT (16-January-2017)

Distributed Systems Software
Victoria, BC

Part 5


Benefits and Advantages

The TGMA architecture offers the following benefits:


Use Cases

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).
    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.

A Use Case in Greater Detail

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.

A detailed use case


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.

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.

Continued in Part 6.


Footnotes

  1. The main purpose of the random "salt" string is to make it impractical for an attacker to take advantage of a precomputed table of password hashes. It also hides the fact that there are accounts with identical passwords (if the salt strings are different, the same password will produce a different digest value). Currently, common practice is for the algorithm to be carefully designed to be strong and computationally intensive, with the system disallowing weak passwords.

    Recent research has investigated password hashing algorithms that are also memory intensive and cannot benefit from parallelization (bcrypt, scrypt, Password Hashing Competition). The goal is to make brute force searches of a captured password file impractical, even assuming that an attacker has custom hardware and powerful parallel processing capabilities. If weak passwords are permitted, however, there is no benefit because an attacker will find them quickly anyway. If "strong enough" passwords are used with a "strong enough" digest algorithm, brute force searches are already sufficiently difficult and there is not a lot to be gained. These brute-force resistant algorithms have a place somewhere in the middle, and they are effective at straightforwardly addressing a real problem.

    But since a password hash computation must be performed for each (legitimate) authentication procedure, brute-force resistant algorithms have a cut-off-your-nose-to-spite-your-face aura because you are also making more work for yourself. Would it not be better to not use conventional passwords at all?

    Extremely weak password management practices continue to be used ("7 million unsalted MD5 passwords leaked by Minecraft community Lifeboat").

  2. If family members share a device, mobile devices not generally having the notion of separate user accounts (this may change for some mobile platforms), only those that have the password for the validator app will be able to use it. Since an individual TGMA account can be assigned a password within a validator, this capability can restrict sign-on to those who know the password.
  3. Manufacturers of these devices have been subject to ridicule for shipping products with passwords like "12345". Customers that do not change the factory password leave their devices wide open to attack.
  4. Internet of Things [] FTC Warns of Security and Privacy Risks in IoT Devices [] "8 ways the Internet of things will change the way we live and work" [] "Beyond the smartwatch: Canada finds its place in the Internet of Things" [] "Internet of Things a playground for hackers" [] "The Internet of Things Is the Password Killer We've Been Waiting For" [] "Why `Smart' Objects May Be a Dumb Idea".
  5. For these devices, rather than selecting a username as such, the interface might test the proximity of the validator, such as by measuring its Wi-Fi signal strength or detecting its Bluetooth connectivity.
  6. Watch as hackers remotely kill Jeep's engine while on highway [] Radio Attack Lets Hackers Steal 24 Different Car Models [] The Web-Connected Car Is Cool, Until Hackers Cut Your Brakes [] Hackers turn off Tesla Model S at low speed [] Hacker shows he can locate, unlock and remote start GM vehicles [] Researchers hack the Mitsubishi Outlander SUV, shut off alarm remotely [] Using a Toy to Open a Fixed-Code Garage Door in 10 Seconds [] Gone in Less Than a Second [] Meet RollJam, the $30 device that jimmies car and garage doors [] Your Smartwatch Could Be A Major Security Risk [] Pair of Bugs Open Honeywell Home Controllers Up to Easy Hacks [] Despite reports of hacking, baby monitors remain woefully insecure [] No building access card? No problem if you have new Def Con tools [] Thousands of medical devices are vulnerable to hacking, security researchers say [] Ransomware Is Coming to Medical Devices [] Why Aren't There Better Cybersecurity Regulations for Medical Devices? [] How hackers can take over nuclear power plants [] New York Discovers Keyless Entry Systems [] 1,400+ vulnerabilities found in automated medical supply system [] Two more healthcare networks caught up in outbreak of hospital ransomware [] Peer-Seeking Webcam Reveals the Security Dangers of Internet Things [] Samsung Smart Home flaws let hackers make keys to front door [] Hackers Make the First-Ever Ransomware for Smart Thermostats [] Implantable Cardiac Devices Could Be Vulnerable to Hackers, FDA Warns
  7. While the average user probably won't think twice about it, handing over your phone number to random companies so that they can authenticate you is not a particularly good idea, despite their promises to the contrary. Some address will be needed for an authentication procedure's callback, but it should be something that is easy for its owner to unilaterally change or destroy, and it should be unique for each account (site). In this respect email addresses are a much better choice, though not ideal.
  8. This can be used to address potentially improper access to information in real time, for instance (Island Health says staff snooped on 198 patient files).
  9. KeySniffer Vulnerability Opens Wireless Keyboards to Snooping