Is there multi-factor authentication for machines?

Question

Most of what I have seen on mutiifactor authentication (eg wikipedia or here on se) seems human centric. Ie it is a human interacting with a machine and the factors are associated with authenticating the identity of the human to the machine. The factors are related to a person:

• something you know (pin, passwords, etc)
• something you have (tokens, cellphone, etc)
• something you are (speech recognition, fingerprints, etc
• somewhere you are (location - you are where you should be, or you are somewhere 'out of place' or 'less trusted')

If all of these, "you" is a person. Single factor authentication is generally 'something you know' and is considered less secure nowadays because of the prevalence of keyloggers, malware, dictionary attacks, as well as all the exploits against the server holding the password. So the security community has come up with these other factors to reduce the risk.

Are there multi-factors for machine to machine communication? Most of our machines communicate via ssh and are 'single factor' (something the machine "knows"). Because it's a machine, 'strong' keys (ie long ones) are used. Because of their length, they are less prone to dictionary attacks. However it is still 'single factor' - once you know the password, the system can be compromised.

Iptables and firewall rules could be considered a second factor akin to 'somewhere you are'. Proper restrictions could help limit the attack surface.

@tom-leek points out the difference between "the threat to a person is impersonation" and "the threat to a machine is subversion". Once a computer is subverted, "what a computer can do, it can do". I am interested in ripple beyond that original subverted computer. Even if I destroy the subverted computer (easy enough to do in a cloud application), the attacker still knows the ssh keys and can use them from other machines (ie it is an impersonation threat). I believe the standard way to mitigate this would be to repudiate that public ssh key. This ripples into many other machines and I was wondering if there were other factors to help with the 'impersonation' threat.

What other 'factors' are there in machine-to-machine authentication?

Answer 1

When authenticating humans, the main danger is impersonation: someone else posing as the expected user. Since humans are biological and not digital, there must be some link between the two worlds: something which ties the concept of the physical identity to sequences of bits on which computers can feed.

We use multi-factor authentication because every single factor we could think of is kinda weak. Passwords can be guessed (they cannot be unguessable because otherwise users would not remember them) or grabbed (by recording with a fast-pace video camera the actual typing of the keyboard -- with a simple telescope, this can be done from several miles away !). Biometrics require visual control (i.e. an armed guard who verify that what goes on the fingerprint reader is indeed a human finger still attached to the rest of the human). Hardware devices can be stolen (especially smartphones, the most stolen kind of object). By piling several factors together, we hope to cope with that crummy situation.

With computers, the situation is completely different. Any computer can contain an extremely robust authentication token, e.g. a big, fat asymmetric key. The main danger for computers is subversion. Indeed, what a computer can do, it can do. Meaning that if a given server is hacked into, then all the "authentication factors" that the server could use are now equally accessible to the attacker. Thus, the scenarios which imply a failure of a computer-controlled authentication factor, i.e. the scenarios in which supplementary authentication factors would be deemed useful, are precisely the kind of scenario where extra authentication factors add no benefit at all.

You could imagine a mixed human/machine setup: computer contains a private key, used to authenticate with other computers, but the key is stored encrypted with a password that the computer does not know; it must be typed at boot time (or possibly at regular intervals). This would bring some additional security, at least in some subcases of subversion. However, servers which cannot reboot in an automated fashion tend to be unpopular with sysadmins.

Answer 2

The only way to authenticate a machine via 2FA might be through the use of a physical dongle or HSM (hardware security module) which could be used to encrypt/sign a message. This is something which could not be stolen by an imposter through logical access to the machine such as secret keys stored on the machine itself could be. The HSM would have to be stolen to impersonate the machine.

Answer 3

You have pretty much hit the two most common ways to identify a machine: - where it is - how it identifies itself

Where it is, and how you determine that, are a function of, well, where it is. On a local LAN many products choose to use the layer 2 MAC address to identify a system. This is not bad, but MAC spoofing is not really that difficult. If your network can do the MAC enforcement at the switch, this is a decent enough security measure, but only as a layer of a multi-layered approach. Another machine on the LAN, if compromised, would not be able to spoof the MAC address because the switch will reject the MAC on a port that it is not allowed to be on. A drawback here is the administrative burden of setting this environment up and maintaining it.

At layer 3 and 4 in the network we can implement traditional firewall/packet-filtering rules. You already mentioned this, and if done right, the effort adds another layer of security. Packet filtering can be done at the host, switch or router/firewall layer of the network, or all 3. The benefit of doing more than one is correlation and anomaly detection.

Keys on a system used for encrypted communications and identification, to prevent a subverted machine from being impersonated, would have to be stored securely, as previously mentioned.

These layers together are the most typical methods used, and if done right (comprehensively) offer a tremendous amount of security. But, it still does not close the loops.

Two more things can be added.

First, device profiling. As mentioned earlier, lots of logging can help with anomaly detection. All of this data feeding in to logs, if correlated, can provide notification; but, only if you know what the host is supposed to be doing in the first place. If Host-A has a purpose to connect with Host-B over TCP/22, this is a regular traffic pattern. If all of a sudden Host-A is trying to connect with Host-B, C and D over a range of ports it is probably something to look at.

So, behaviour becomes a factor of identification. (This is kind of like identity systems that try to match the way you type in your password, so that even if someone else knows what they password is, the way it is entered would be different. For instance, the way I type "password" at the keyboard would be completely different than a brute-force password guesser automatically sending the string.)

Network Admission/Access Control (NAC) is another way you could identify a machine. What processes are running? What software is installed? An agent would have to collect that information and provide it to some other system that would make a decision as to whether it should be permitted on the network. Again, now we are profiling the machine. This gives us another view of whether the machine is the machine. Tripwire, the really old version, and the new one, also do something like this by hashing all of the files. This can be very helpful because a subverted machine may become the 'bad-guy'. Now the 'bad-guy' looks legitimate, but it may have malicious software installed, or files that are replaced.

So, making sure a machine really is that machine you think it is needs to be more than just two-factors. A subverted machine is still the system that you thought it was, but it could also be more. So, an important factor in making sure that systems are what you think they are is profiling the system itself, and what it is doing on your network, or with the other systems that it interacts with.

Answer 4

Authorizing a machine sounds like a boolean decision, but you can design distributed applications so that machines are mutually suspicious.

Observe that stealing a secret only makes it easier to abuse authority if you can forge a message describing the authority you want to exercise, so making messages harder to forge can act as a second factor.

In the authorize-only model, a machine receives a message

+----------------------------------+
|Header: secret-key                |
+----------------------------------+
|Body:                             |
|debit account for Alice Smith     |
|credit account for Craig McEvil   |
+----------------------------------+

with a secret in the header, or signed with a secret, and the receiving machine acts on all messages so signed.

Instead of trusting any message that arrives with a single key, which allows someone who steals the key to forge messages, you can make the messages themselves harder to forge by identifying principles using unguessable (aka crypto-strong PRNG) identifiers, so your message might look like

+----------------------------------+
|Header: secret-key                |
+----------------------------------+
|Body:                             |
|debit account for ASVX009I...     |
|credit account for OAbB73I9...    |
+----------------------------------+

so only if an attacker can also obtain an opaque, unguessable identifier can they drain an account, thus reducing the risk of systematic failure.

Further, if you need to steal multiple machines' keys to both obtain an account identifier and debit the account, you have raised the bar to an attack and widened the window during which your intrusion might be detected.

Answer 5

Yes. e.g., certificates combined with shared secrets. I see this being used in proprietary backup solutions, e.g.., the certificate is requried to even talk to the authentication subsystem, then a one-time password being applied on login (and changed at logout).

Even if the machine is duplicated, the certificate won't get you far (unless you're duplicating the machine within 24 hours of the last password change)... and even then, the breach will be detected within the next backup cycle.

One might argue that this isn't multifactor authentication, but instead layered security, but I think the difference is semantics. If you don't have the certificate, the password is useless. If you don't have the password, the certificate is useless. It's two factor in my books.

On top of that of course, the firewall is restricting the source IP, but I think that might be a stretch since that information is not well protected.

Answer 6

Physical unclonable functions provide a strong "something you are" factor for machines. Such functions can be found in your PC, but it is also possible to design in support for PUFs, for example by using an FPGA.

To use a PUF to authenticate a machine, the verifier needs to know a challenge response pair. It is possible to use this to build strong authentication functions.

A detailed overview of PUFs is given in this paper.