Date: Mon, 3 Mar 1997 19:23:15 -0800 From: "Bob Atkinson (Exchange)" Subject: Comments and corrections regarding Authenticode As the architect and primary implementor of the Authenticode code-signing technology (boy, that'll get me mail :-) found in Internet Explorer 3 and in Windows NT 4, I think my perhaps somewhat lengthy and clearly very biased perspective on some recent articles might be of interest to others. Bob Atkinson > From: "Theodore Y. Ts'o" > Subject: Re: Myths about digital signatures (Felten, RISKS-18.83) > > For example, if an Active X component has a loophole where (with the right > document) said component can be induced to interpret and execute arbitrary > Visual Basic statements, even if the signer was honest, and legitimate, and > properly went through all of the Microsoft certification procedures, it > still might be possible to exploit a security bug in the Active X component. First, a correction. Microsoft does not have any 'certification procedures' with respect to the integrity or lack thereof of third party applications against security attacks. There is no magic bullet that would enable us to make such statements. Software developers, as they always have been, have the responsbility of themselves exercising appropriate diligence in this regard. We do, however, offer system services that aid developers in this endeavor. For example, the underlying Authenticode engine is available for use by applications so that, say, if they themselves are an execution engine which might from time to time download possibly malicious code, they can apply the same gatekeeping checks as the system's download engine applies. This was, exactly, intended to address the scenario describe here (see the "WinVerifyTrust API" if anyone is interested). As another example, the overall system infrastructure, which includes the Java VM and its attendant sandbox, has mechanisms for classifying ActiveX components as "safe for scripting" and "unsafe for scripting;" a similar mechanism applies to "safe for initialization" (from data on web pages). These are designations assigned by the ActiveX component developers themselves. In short, components that designate themselves as 'safe for X' can be interacted with by (possibly malicious) code inside the sandbox; code designated as 'unsafe for X' is prevented by the system from being instantiated or interacted with by sandbox code. The point being that the system provides the component developer flexibility in balancing his development time and effort with the amount of richness available to his component once downloaded. > The Java security model at least *thinks* about this issue, where as the > Active X approach completely punts about this concern. Having spent considerable brain cycles on the issue over the last couple of years, you'll I hope pardon me if my opinion differs from the thought expressed here. Users want and demand a rich computing experience. Users want software that does interesting, important, and useful things for them, be that Navigator plug-ins, arbitrary EXEs, .Zip files, Java (system) classes, ActiveX controls, or something else. The same security issues being discussed with respect to ActiveX apply equally to all these _other_ forms of application, all of which in the course of doing interesting and useful things on behalf of the user is going to at times need to be given access to information or capabilities that _could_ be used for evil instead of goodness. With traditional software distribution channels (Egghead, Computer City, ...) you know where the code came from because it says so on the box, and you trust the retailer to sell you only legitimate product that hasn't been tampered with. Got a problem with the program? The guy on the box is who you call; he sure doesn't want the embarrassment or liability of shipping product that ends up having a virus in it, so he takes care not to do so. The combination of criminal and tort laws together with a company's desire to stay in business and enhance its reputation works together to create a system that supplies customers with rich, useful software at a minimum of risk. We have decades if not centuries of experience with this model of conduct between supplier and customer. It seems to work pretty darn well. In the online world, users have heretofore installed software manually, by way of manual download. In doing so, they have had to resort to ad-hoc and often naive mechanisms for judging the risk they are taking in doing so. "Just where did this code come from? Who is responsible for what it does? And has it been tampered with? How do I know?" The online distribution channel has lacked mechanisms that provide the accountability present in traditional channels. We can make users lives dramatically better by automating the online software installation process. The rich, useful code can just always be simply there right when you need it, rather than your having to understand what code it is you're missing, hunting around to find it, and having to have the computer experience to figure out how to manually install it. In addition, we can provide mechanisms that bring to bear in the online world the same forces successfully used to manage risk in traditional channels, mechanisms that can help users be conscious of the risks involved and make informed choices about them. These mechanisms are particularly important to have in place when installation is automated, as it is in IE3, but the mechanisms are also valuable and useful even when installation is done manually. > From: fc@ca.sandia.gov (Fred Cohen) > Subject: Re: MS on the CCC ActiveX virus (RISKS-18.83) > I appreciate your [BradSi's] insightful opinion on this matter, however... > Anyone can get a signature key without authenticating their legitimacy. > It's relatively easy to break into a system and take a legitimate key. It is true that the user's understanding and the care with which he manges his private key is an important part of an overall security infrastructure. Flaws in any one part of that overall infrastructure may compromise the system as a whole. However, compromise of private keys is a concern that IMHO warrants less worry than other aspects of a system might. In Authenticode as implemented in IE3 and NT4, the private keys are managed by the system's cryptographic provider infrastructure (CryptoAPI), which enables a number of different cryptographic devices to be used transparently by applications. Several different cryptographic hardware devices are on the market that support CryptoAPI, offering extraordinarily good, virtually foolproof private key protection in a range of prices from a couple of hundred to a few thousand dollars (see, for example, http://www.spyrus.com/whats_new/pr_csp.htm, or http://www.bbn.com/offerings/sksign.html ). Such hardware devices and the increased key protection they provide are likely to be well worth the investment, especially for commercial enterprises in the business of software publishing. Indeed, from my own personal perspective it can be argued (disclaimer: I am not now, nor ever have been a member of the legal profession) that given the modest costs and given the nature of being in the software business to not take such precautions might be considered negligent on the part of such an enterprise. For those curious: at the present time, the private keys with which Microsoft signs code that it publishes are managed inside BBN SafeKeyper boxes housed in a guarded steel and concrete bunker. Even were a SafeKeyper to somehow be physically stolen, these cool little boxes have several elaborate internal defenses designed to have the box destroy itself rather than compromise its keys. As I understand things, a military variation on the SafeKeyper technology is used as an integral part of launch control of nuclear missiles on submarines in the US Navy. In the absence of a hardware device, CryptoAPI provides an in-the-box a software-implementation of the cryptography; however, when this cryptographic provider is used with Authenticode, the private key is not in fact kept online, but rather on a floppy disk, which need be inserted only during the actual act of code signing, hopefully on a managed, virus-free 'release environment' machine used to protect against this and a whole host of other more traditional potential virus attacks. > The default may be changed by the user for one use and remain changed. > Other flaws in Explorer may be used to turn that feature on - then look out. > > The CCC demonstrated its malicious executable code running on Microsoft > > Internet Explorer 3.0 This is true, as the demonstration was made, but it is misleading, as it leaves out significant contextual information. The CCC demonstrated code which, if it had been actually deployed, would, as I understand things from the press descriptions I have seen, carry out actions which are out-and out-theft. Theft is illegal. You can go to jail for it, if they catch and convict you. Let's look at that for a moment. There are the following ways in which that malicious code could get on a user's machine: 1. The user can choose to bypass the security support provided by the system by setting his security level to 'none' or 'medium'. The CCC control was unsigned, and thus cannot be installed by IE unless the user overrides the protection provided by the system. 2. The code could be signed, and then downloaded by IE3, and accepted by the user. That is, the crooks can if they like leave their clear, unsmudged fingerprints all over their illegal device. This makes catching and convicting the responsible party somewhat easier. 3. Some well-intentioned software agent other than IE3 can download and install the malicious code. Such agents, would, however, have the same responsibility for exercising due diligence in protecting the user as IE3 itself has. Fortunately (see above), the mechanisms are available in the system infrastructure to allow them to do this. In the absence of the user bypassing the system's security infrastructure, which as was mentioned is highly discouraged, then should the system be attacked by a malicious ActiveX control, some piece of malicious or negligent digitally-signed code that was downloaded is ultimately responsible for carrying out the attack or allowing it to occur. The mechanism which prevents this from happening is the deterrent of a reasonable expectation of getting caught and being held accountable for one's actions. This is the same mechanism used to great effect in the rest of a free society to balance freedom of action and unencumbrance by red tape with society's need for safety and protection. The presence of digital signatures on code does not remove the need for law enforcement agencies to do their investigative work when confronted with a crime; their detective and analysis skills will continue to be be valuable and needed. Even in the absence of an audit log of execution (a very good idea, where technically feasible), if you eat hamburgers at Restaurant X, and you get sick, and Fred eats hamburgers at Restaurant X, and he gets sick, and so on, chances are that there's something wrong with the hamburgers at Restaurant X. Or if you drink fruit juice from Company Y ... you get the idea. Effective and successful criminal prosecutions are regularly and routinely made on less than perfect evidence, often _much_ less clear than we're discussing here. What digital signatures on code provides is a robust and unforgeable attribution of responsibility for publication once the actual offending code is identified. And, as implemented contractually and technically in the present release of Authenticode, when you sign code you _are_ most certainly taking explicit responsibility as the code's publisher, an action not to be taken lightly from a legal point of view. The additional ability to have third parties digitally "endorse" or "rate" works published by others we have always thought to be a very useful and valuable concept, but it is a separate and distinct one from that of signing as the publisher. > As the folks at Microsoft know well, impediments are easily and commonly > removed - and the use of the display box for popular applications is > likely to result in the question being turned off in favor of easy access. Yes, the concern that inconvenience or annoyance causes the end-user to bypass the security infrastructure (see #1 above) is an important consideration. However, I am optimistic given our experience to date that we've done well in this regard, though only time will tell for certain. Educating users not to lower their security level is extremely important; we're working very hard on educational initiatives like the Security Advisor program (http://www.microsoft.com/security). Moreover, in the Authenticode infrastructure is the notion that one can come to 'trust' certain publishers. Code that is legitimately signed by a software publisher who is listed by the user as trusted is automatically approved for installation without user intervention. For example, if Microsoft Corporation were listed, then code signed as being published by Microsoft will be downloaded and installed without any dialog box or other repeatedly-annoying UI. The net effect is a mechanism that allows the user to bypass redundant and repeated prompts for the same approval _without_ compromising his protection in any way. Within intranets, even greater protection can be achieved by enforcing download and signature-checking policy within a company's firewall. This can be done, for example, with TIS's Gauntlet Internet Firewall (http://www.tis.com/docs/corporate/press/96/mspr.html). > From: Steve_Kilbane@cegelecproj.co.uk > Subject: Re: MS on the CCC ActiveX virus (RISKS-18.83) > > > [MS Press Release:] Other firms such as Sun and Netscape are > > following our lead, and have > > announced that they will also provide code signing for Java applets. > not only are Microsoft > attempting to justify giving away the family silver, but they're also trying > to imply that they're the ones responsible for the idea of code signing [...] > I wasn't following Java back when it was called Oak and set-top boxes were > the name of the game, but I wouldn't be hugely surprised to discover that > signed code was part of the plan even then. Anyone with more authority care > to comment? I think too much is being read here into our press release. Invention of basic ideas and usable, successful, practical wide-spread deployment of implementations of ideas are different beasts. Both are important, and both are needed. Both require some amount of creativity and innovation. The general notion of digital signatures has been around for quite a while. Just to take one example implementation from many possibilities, Apple some time ago shipped in their OS a "digital signature on documents" infrastructure (whose name alas escapes me at the moment). The relevant technical standards used in Authenticode (X.509 and PKCS #7) are also not new by any stretch of the imagination. With respect to signed _code_, various Java-related web pages on the Sun web site circa early summer 1995 indeed did mention in passing that it was an interesting idea to apply digital signatures to code. Clearly Sun was at that time exploring this interesting idea. However, no insights were offered as to the actual policies or architecture that might be involved. To be just a little overly-severe, what I recall was little more than simply "digital signatures" and "downloaded code" being mentioned in the same sentence. IMHO, the most important innovations of Authenticode on prior general practice in the industry lie in the area of usability, especially as related to the user's understanding of and administration of trust. You might notice, for example, that the certificate dialog simply states "X is published by Y under credentials issued by Z," as in "Surround Video Control is published by Microsoft under credentials issued by Verisign" a simple "brand of identity" approach rather than the historical approach of thrusting upon the user a whole chain of delegated identifications. Also, appropriate clickable hyperlinks are provided on the prompting dialog, allowing both the publisher to set appropriate expectations with the user as to what his code is going to do, and for the credentials agency to inform the user of its identification policies, all before the user has make the decision of whether to allow any of the publisher's code to run or not. Third, as was mentioned, repeated prompts for essentially the same approval can be easily and simply automated without loss of security. Fourth, the fact that we focused on mechanisms whereby signatures can be physically inserted within existing file formats (.EXEs, .CAB, .class, etc) rather than as separate files increases usability by avoiding the need to keep multiple files in synchronization. None of these ideas is by itself especially deep. But taken together, I submit that the overall user experience is significantly more straightforward. Finally, there is the simple fact that despite the (welcome!) future plans in the area of code signing expressed by both Sun and Netscape, Authenticode is still the only actually-deployed code signing infrastructure. It's seven months into widespread shipment, nine or ten months since it's first beta, close to a year since its first public demonstration, and close to fifteen months since it's announcement. Ideas are important, but it's difficult to impact users unless you actually ship product.