From vin@shore.net Tue Jul 23 07:07:24 1996 Received: from relay1.shore.net (root@relay1.shore.net [192.233.85.129]) by suburbia.net (8.7.4/Proff-950810) with ESMTP id HAA13701 for ; Tue, 23 Jul 1996 07:06:41 +1000 Received: from [206.243.168.223] (slip-22-23.slip.shore.net [206.243.168.223]) by relay1.shore.net (8.7.5/8.7.3) with SMTP id RAA29235; Mon, 22 Jul 1996 17:04:57 -0400 (EDT) X-Sender: vin@shell1.shore.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Jul 1996 17:03:10 -0400 To: firewalls@greatcircle.com From: vin@shore.net (Vin McLellan) Subject: Authentication necessary when encryption ? Cc: calt@tla.ch, adam@homeport.org, best-of-security@suburbia.net Christian Alt petitioned the Brethern here assembled for discussion of a serious question -- one too often ignored; yet likely to be heard more often in the future. Said Mr. Alt: >With encryption between a remote user's laptop and the central site, do >you think that authentication is still necessary. This is the point on >which i would like to exchange some thoughts. > >I admit that the encryption keys are unique to any user. > >Authentication is still necessary to access the ressources on the central >site. But no more to access the site itself. Mr. Alt raises the issue in a particularly subtle way. He asks on one hand whether encryption, per se, could serve as an authentication process -- and then, on the other hand, he suggests that any such an authentication (implemented solely on the basis of possession of a unique encryption key) could be used with some limitations, in a process where it would be honored only to the extent of providing a remote user "access" to a host network or remote system. Some further, more extensive, (two-factor?) authentication, he implies, might/would/should be required to actually access (data or system) "resources" on the protected system or network. >In case that a laptop get lost, the site can be compromised. This is a >risk we can accept or refuse. This is complex model in that it presumes that "access to the site" can be allowed without serious risk to the site's resources. At least with conventional CPUs (vulnerable to, at least, virus, trojan, and worm attacks -- even with bug-less code and perfect implementation) security, integrity, and access controls seem most effective and trustworthy when applied at an outer perimeter: in a hardened gateway to the protected net, domain, or host. Hence, the Creed of the Firewall. But Mr. Alt's deceptively simple query also raises several big issues. It's a concern of mine, so I beg his -- and Your -- indulgence for a longish response. I. Are encryption and user authentication different? Mr. Alt presumes, correctly I think, that they are, but the distinction is seldom reasoned out. * Crypto guarantees secrecy and data integrity, notably. (Yet, whatever the security of the encrypted data in transit, it is only as secure as the procedure at the end-points to get the transmission into the hands the proper party. In most implementations, crypto is only as strong as the user authentication associated with it.) * User identification and authentication (I&A) allow us to implement access controls, which constrain access to executable processes as well as data, and establish accountability with audit trails. (Encryption can only serve as a factor of authentication -- and thus, to an extent, function as an authenticator -- when the encryption key is assigned with a granularity down the individual: with each user in possession of his own encryption key. This raises implementation issues -- i.e. key storage and transport -- that must be addressed. It is among people who ignore those issues that there exists the {unfortunately widespread} illusion that with end-to-end encryption, authentication becomes as a freebie. A nifty feature available at no additional cost.) II. Within virtually all organizations, access controls and secrecy/confidentiality are different functions -- politically, as well as technically. They serve, quite literally, different masters. * Access control privileges are generally assigned by a local manager, a manager of people. On the other hand, the designation of data as secret or confidential (or requiring ongoing integrity checks) is generally done by the manager or developer of an application -- in most organizations, a different fellow than the aforementioned local manager. The local manager probably doesn't know the heritage of the data or fully understand the relevant issues of confidentiality. The applications manager probably doesn't understand what specific access privileges a given employee requires to do his job; certainly not enough to appropriately minimize that employee's access. * These are divergent chains of responsibility and authority, and the import of this distinction is compounded by the reality that, typically, the life span of the application is much longer than the tenure of any one employee. (People can be managed by transient managers, in part because a person can explain himself and his role. A long-lived application may, on the other hand, require someone with a deep understanding of the heritage of the data and its legal, moral, and political associations, to specify -- or adjust -- its info-security classification.) * The implications of combining control of encryption (secrecy/confidentiality) and access control in one function or a single individual can be dangerous. Often, this would create an administrative task in a vacuum -- a place where the organization doesn't have a designated or appropriate area of responsibility, or a role sufficiently informed to carry it off. III. It is useful to compare relative modes of authentication offered by a user-specific encryption key and a "strong" (two factor) authentication device. The basics: * Strong authentication -- especially, tokens which require a PIN -- were designed to address the needs of mobile users. (In reference to the point above: note that it is unusual for a highly mobile user to be limited to accessing a single application; rare indeed for all users of an app to fit the same user {access control} profile. Again, a tale of two masters.) * The hoary list of identifiers Adam Shostack cited -- "something you {have, know, are}, pick any 2" -- is a classical distinction in the lore of IS because those three factors of (machine-mediated) authentication depend upon separate and independent mechanisms. Two-factor authentication is valued because even if an attacker somehow obtains one identifier, the repository of a second factor remains secure without a second direct attack. * One-time passwords (OTPs) first became popular in unencrypted networks because they used a bit of crypto to foil eavesdroppers who might capture a static password and later gain illicit access to a user's account, machine, or network. The replay attack. Yet many OTPs offer more; they almost always offer two-factor ID authentication... and the most popular can also place a time-constraint around a user's access (the OTP is valid now; but not ten minutes from now.) The latter is a constraint not easily available with straight crypto. * Is an encryption key a valid identifier? Of course! A properly-keyed encryption engine at both ends of a data link is evidence of a shared secret (in symmetric crypto,) or a negotiated secret (in public key crypto) in both machine A and machine B. But what this means -- even with each user holding a unique key -- varies, depending upon the context and implementation. (Some encrypted links can also be vulnerable to man-in-the-middle attacks.) * Typically -- given that crypto keys are often long and impossible to remember -- the presence of the key is evidence that a remote user has possession of something (a "loaded" token: a diskette, hard-disk, smart card, or PCMCIA card) previously assigned to a specific user. * Can a device holding an encryption key (PKC secret key or "simple" secret key) be designed to require a PIN or the equivalent from the user to be activated -- offering "two-factor" authentication? Certainly! Implementation can be trivial (PIN-protected memory cards are already on the market, or an encrypted PIN could be transmitted with the message) or complex: with a memorized password hashed and converted into a 56-bit DES key... or maybe the seed for an RSA key-pair generator. (Note: Even if the key itself is derived from the hash of a memorized password, the software that receives and transforms that password will have to be protected and probably carried by a mobile user. Storage and transport.) I'm personally intrigued by the possibility of using the unique features of RC2 in the RSA Secure package for PCs -- where a memorized password might be transformed into one of the _two_ keys required to encrypt or decrypt a message stream. (The token would hold one; the user, the other. Then, evidence of two factors would be carried all the way to the distant host for true two-factor authentication.) In any case, it is clear that properly implemented encryption _can_ provide full two-factor authentication. Yet, as with so many things, the burden of the concept is in the details. And so the question: IV. Where do you keep your crypto key? We might start with the suggestion that an encryption key is often far more valuable to any hostile party than any one-time password can be. At worst, a compromised OTP opens up the user's account and information available to that user on-line -- but this is typically a self-healing breech. (Either a single OTP {offering only one penetration} is compromised, or the user/audit system/sysadmin spots the penetration and closes the hole.) A crypto key compromised, however, can potentially open up all past and future communications to eavesdroppers -- and such a compromise may be very difficult to recognize or acknowledge. This can raise the stakes for all parties. While the limited value of a stolen OTP device may not justify the risk and cost of compromising that system; a crypto key may be a juicier target -- worth of whatever risk and whatever the cost to obtain it. That said, we get to the mechanics, the physical question of where we store the encryption key (particularly, for our so-mobile remote users.) There are four obvious options, in a: * PC (hard disk,) * floppy diskette; * smart card; or in a * PCMCIA card. Each is a legitimate option, but each also carries with it various risks and costs. Storing the key in a laptop or palm-top PC, for instance, makes it vulnerable to theft (a growth industry in the black market,) and all the subtle and heavy-handed attacks possible against a relatively-unprotected software asset. (Even if stored encrypted, the key inevitably becomes visible to other processes within the PC whenever it is used.) Storing the key on a diskette gives the user mobility without much bulk -- but diskettes are even easier to analyze and reverse engineer than a software secret on a hard disk. Solutions that call for storing the key in a disk or diskette all carry high risks for the stored secret. The third option, the smart card, is moderately secure. Although the science of attacking and reverse-engineering smart cards has been developing rapidly, such attacks remain costly in talent, time, and equipment. (Here again, while the advantages of a obtaining one-time password are seldom seen to justify such an expenditure, the value of a crypto key might.) The fourth option, the PCMCIA card is a hardware implementation which is generally seen as robust. It probably offers the highest degree of security for your key. In summary: TANSTAFL. There ain't no such thing as a free lunch. (Non-Yanks: Please pardon the grammar and ignore the double-negatives.) Encryption can offer aspects of authentication, but implementing encryption for mobile users requires secure storage of the key for transport. Administering the assignment and distribution of a secret key, in whatever storage device, will create significant overhead -- much like administering OTP tokens. While it seems likely that the next generation of OTP tokens will be devices which will also carry crypto keys (if not full encryption engines,) there doesn't seem to be a cheap shortcut. To use an encryption key as an authentication device raises unique administrative and management issues; and often requires a complex, labor-intensive, system for the purchase, programming, and secure distribution of whatever physical devices are chosen carry the encryption key. I hope this is helpful, Christian. (And I'm eager to receive criticism or comments on these thoughts.) Suerte, _Vin Vin McLellan +The Privacy Guild+ 53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548 <*><*><*><*><*><*><*><*><*>