📄 sweep077.htm
字号:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<HTML>
<HEAD><TITLE>Introduction to Code Signing</TITLE>
<STYLE>
#tctop {color: red}
#cpslug {color: red; text-decoration: none}
</STYLE>
</HEAD>
<BODY TOPMARGIN=10 BGPROPERTIES="FIXED" BGCOLOR="#FFFFFF" LINK="#000000" VLINK="#000000" ALINK="#000000">
<FONT FACE="ARIAL,HELVETICA" SIZE="2">
<TABLE BORDER=0 ALIGN=RIGHT><TR><TD VALIGN=TOP>
<A HREF="sweep076.htm" TARGET="TEXT"><IMG SRC="u_prev_3.gif" WIDTH="30" HEIGHT="30" BORDER=0 ALT="Previous"></A>
</TD>
<TD VALIGN=TOP><A HREF="sweep078.htm" TARGET="TEXT"><IMG SRC="u_next_3.gif" WIDTH="30" HEIGHT="30" BORDER=0 ALT="Next"></A>
</TD></TABLE>
<H2><A NAME="codesign_0001090102000000">Introduction to Code Signing</A></H2>
<BR CLEAR=ALL>
<P>This section is a general introduction to code signing. A later section will discuss Microsoft's Authenticode technology, which helps developers easily sign their code.
<P>One of the larger questions facing the software industry is this: How can users trust code that is published on the Internet? Currently, most Web pages contain only static information, but soon they will be filled with controls and applications that are downloaded and run locally, on the user's computer.
<P>Packaged software uses branding and trusted sales outlets to assure users of its integrity, but these are not available when code is transmitted on the Internet. Additionally, there is no guarantee that the code hasn't been altered while being downloaded. Browsers typically exhibit a warning message explaining the possible dangers of downloading data, but do nothing to actually see whether the code is what it claims to be. A more active approach must be taken to make the Internet a reliable medium for distributing software.
<H3><A NAME="codesign_0001090102010000">Ensuring Integrity and Authenticity</A></H3>
<P>Two issues must be addressed:
<UL><LI>Ensuring authenticity, which means assuring users that they know where the code came from.
<LI>Ensuring integrity, which means checking that the code hasn't been tampered with since it was published.
</UL>
<P>Microsoft's solution to these issues is Authenticode coupled with an infrastructure of trusted entities. A discussion of the infrastructure is included in the explanation of certification authorities later in this section. Authenticode, which is based on industry standards, allows developers to include information about themselves and their code with their programs through the use of <I>digital signatures</I>.
<H3><A NAME="codesign_0001090102020000">Digital Signatures</A></H3>
<P>You use digital signatures when you have data you want to distribute, and you want to assure the recipients that it does indeed come from you. Signing data does not alter it. It simply generates a digital signature string you can bundle with the data.
<P>Digital signatures are created using a public-key signature algorithm such as the RSA public-key cipher. A public-key algorithm actually uses two different keys: the <I>public key</I> and the <I>private key</I>. (These are called a key pair.) The private key is known only to its owner, while a public key can be available to anyone. Public-key algorithms are designed so that if one key is used for encryption, the other is necessary for decryption. Furthermore, the decryption key cannot reasonably be calculated from the encryption key. In digital signatures, the private key generates the signature, and the corresponding public key validates it.
<P>In practice, public-key algorithms are often too inefficient for signing long documents. To save time, digital signature protocols use a cryptographic digest, which is a one-way hash of the document. The hashed document is signed instead of the document itself. Both the hashing and digital signature algorithms are agreed upon beforehand. Here is a summary of the process:
<OL><LI>A one-way hash of the document is produced.
<LI>The hash is encrypted with the private key, thereby signing the document.
<LI>The document and the signed hash are transmitted.
<LI>The recipient produces a one-way hash of the document.
<LI>Using the digital signature algorithm, the recipient decrypts the signed hash with the sender's public key.
</OL>
<P>If the signed hash matches the recipient's hash, the signature is valid and the code is intact.
<P>When code is associated with a publisher's unique signature, distributing software on the Internet is no longer an anonymous activity. Digital signatures assure accountability, just as a manufacturer's brand name does on packaged software. If an organization or individual wants to use the Internet to distribute software, they should be willing to take responsibility for that software. This approach is based on the premise that accountability is a deterrent to the distribution of harmful code.
<H3><A NAME="codesign_0001090102030000">Public-Key Certificates</A></H3>
<P>Public keys, because they are public, are vulnerable to attack. In particular, an unscrupulous individual may want to substitute one public key for another.
<P>For example, if Microsoft wants to send an encrypted message to Bob, an independent developer, it goes to the public-key database and gets Bob's public key. Unfortunately, Bob has a rival named Trent. Trent is not only a rival, but a sneak as well. He has substituted his own key for Bob's in the public-key database. Microsoft encrypts a message in Trent's key and sends it to Bob. Trent intercepts the message, decrypts it, and reads it. Finally, he re-encrypts it with Bob's key and sends it on to Bob. Neither Bob nor Microsoft know what has happened.
<P><I>Public-key certificates</I> are used to prevent this situation. A certificate is someone's public key, signed by a trustworthy person or organization. If Bob has a certificate in the database, it contains much more than his public key. It contains information about Bob, such as his name and address, and it is signed by some entity Microsoft trusts.
<H3><A NAME="codesign_0001090102040000">Certification Authorities</A></H3>
<P>Trustworthy persons or organizations are called <I>certification authorities</I> (CAs). Certificates are verified through a hierarchy of these CAs. Each certificate is linked to the certificate of the CA that signed it. By following this hierarchy, or <I>verification path</I>, to a known, trusted CA, you can be assured that a certificate is valid. An example of this is illustrated in the following diagram.
<P><IMG SRC="code1.gif" WIDTH="536" HEIGHT="432" ALT="" >
<P>
<B>Sample Certification Hierarchy</B>
<P>
<P>In this example, Netwerks' certificate is certified by CA1 while Bob's is certified by CA3. Netwerks knows CA1's public key. CA2 has a certificate signed by CA1, so Netwerks can verify the CA2 certificate. The root also has a certificate signed by CA1. CA3 (Bob's CA) has a certificate signed by the root. By moving up the verification chain to a common point (in this case, the root), Netwerks can verify Bob's certificate.
<H3><A NAME="codesign_0001090102050000">Duties of Certification Authorities</A></H3>
<P>Certification authorities have two main duties:
<UL><LI>They publish the criteria for granting certificates.
<LI>They grant certificates if an applicant meets the published criteria.
</UL>
<P>Other duties may include:
<UL><LI>Managing certificates (for example, enrolling, renewing, and revoking them).
<LI>Storing root keys.
<LI>Verifying evidence submitted by applicants.
<LI>Providing tools for enrollment.
<LI>Accepting the liability associated with these responsibilities.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -