Remote Safety

Almost since the first time-sharing computer was accessed with  a dumb terminal, a phone line, and a modem, maintaining the security of remote access has been the concern of system administrators.  We use passwords, of course, but these suffer from a number of potential problems,  as I’ve discussed before.  Two-factor authentication schemes have been used in an attempt to bolster security, but they can be attacked, too.

Now Technology Review has an article about a new approach to two-factor authentication, which uses as the second factor (“something you have”) characteristics of the user’s device.  The system discussed, EdgeID, is produced by a California company called Uniloc:

To use EdgeID, users must first register a device, such as a laptop or smartphone, by installing a small software program. The program collects about 100 pieces of information about the device, ranging from basic facts like the hard disk serial number to details that evolve through wear on the system, such as the locations of bad sectors on the hard drive. These details are then transferred to a central server, which also runs software from EdgeID.

Apparently, the system maintains a dialogue between the central server and the client, in which the server periodically asks for specific items of information (e.g., what are the last two digits of the disk drive serial number).  The system can be configured to take various actions when the authentication conversation is unsuccessful: write a log message, force the user off, or limit access in some other way.

This is a fairly clever idea, and may help to protect against unsophisticated attacks; possibly more important for corporate users, it could provide a warning that an “unofficial” device is trying to log in.  However, the system shares a basic problem with many remote authentication schemes, including things like biometric readers.   What is actually being checked is a digital encoding of some information (such as a disk serial number or a fingerprint image) versus an “authentic” encoding stored in a data base somewhere.  If the authentication conversations are not encrypted (and it is not clear from the article whether the EdgeID system does this), they are potentially vulnerable to a so-called “man in the middle” attack.  Even if they are not, the security of the central data base must be carefully guarded.

Another potential problem is that, often, systems may provide facilities to lie about their components.  For example, Ethernet network interface cards [NICs] have a 48-bit MAC (hardware) address assigned by the manufacturer, a number typically displayed in the form ’01:23:45:67:89:ab’.  Written material occasionally (and incorrectly) suggests that this can be used to reliably identify a particular NIC.  But, at least on Unix/Linux systems, the ifconfig(8) command can be used by the ‘root’ user to set the reported address to any desired value.  (I have used this myself, when on vacation in a rented house, to use the installed WiFi router which was configured to accept only certain MAC addresses.)

Still, the idea of using device characteristics as part of the authentication process has some merit.  After all, as I have written before, our customary  methods of identifying people have not depended on a single characteristic, but on what can be fairly described as a probabilistic assessment:

At the root of many traditional methods for verifying a person’s identity is the notion that the only person likely to know a large number of disparate facts about a particular individual is the individual himself.

So a similar approach with hardware, especially hardware that has some built-in security features, like the TPM on some PCs, has the potential to help keep the Bad Guys out.