?? 216-219.html
字號(hào):
<!-- Edit EirGrabber 3.01 -->
<HTML>
<HEAD>
<TITLE>Smart Card Developer's Kit:Smart Cards and Security</TITLE>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="214-216.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="219-221.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<P><FONT SIZE="+1"><B><I>Certifying Authorities</I></B></FONT></P>
<P>Most trust models in this emerging infrastructure are based on the concept of a certificate which ties real-world identification information for an entity together with a public-key component of a public/private key pair to be used to authenticate identity in an electronic environment. A certificate is to be issued by a certificate authority, which is some person or entity that will attest to some degree to the connection of identity information to a public key.
</P>
<P>One variant of this model makes use of the trust between individuals who know each other to build a chain of trust from one individual to another when the two may not actually know each other. In this model, one receives a public-key and associated identity information from a person they know and who will vouch for the information received. This model could be seen to work for relatively small numbers of individuals, but its applicability for handling very large numbers of individuals is still being explored.</P>
<P>Large-scale trust models are currently rooted in the concept of a certifying authority or even hierarchies of certifying authorities. That is, organizational entities known as certificate authorities (CAs) perform the service of validating identity information, associating that information with a specific entity (person or organization), and associating all this with a public key. This attestation is provided in the form of a document (a certificate) that is digitally signed by the CA. The intent is that the CA forms a trusted third party to all two-way transactions. If two different parties can each trust the CA, then they can trust the information received from the CA (certificates) and hence can trust each other if each has received a certificate from the CA.</P>
<P><FONT SIZE="+1"><B><I>Certificates</I></B></FONT></P>
<P>A certificate is a set of information that connects a physical identity (for example, a name, an address, a telephone number, a Social Security number, a driver’s license number) with the logical identity represented by a public/private key pair. Here’s an example:
</P>
<PRE>
Serial Number = 889fba340000000000010000000000
X.509 Certificate Signature Algorithm ID:
{ 1 3 14 3 2 13 } == SHA-WITH-DSA-SIGNATURE
X.509 Certificate Signature Algorithm parameters:
30 5a 02 20 c2 0a 28 7b f5 7e ce 13 c2 a3 6e 72 92 c7 13 67
d9 8f 15 73 e2 ea 19 b1 67 8f 80 f8 8a d4 c2 a3 02 14 ff 9a
ff a2 7b 05 01 2e 99 a8 49 a8 cb 7f d6 ab fd 68 2f 1d 02 20
c0 c9 2d 97 f5 28 11 f5 3b 8d 81 8c 02 59 67 2a 54 25 4b 81
ae 91 c3 70 f9 9b 90 cb de f3 2b 9e
Issuer Name: /C=USA/O=SmartCommerceCorp
Not Valid Before: 12:39:16, 08/30/1997 GMT
Not Valid After: 12:39:16, 11/28/1997 GMT
Subject Name: /C=USA/S=NY/L=Albany/O=SmartCommerceCorp/OU=Sales/CN=Jane
Doe/T=Sales Manager
Subject Public Key Algorithm: { 1 2 840 113549 1 3 1 }
== Diffie-Hellman
Subject Public Key Algorithm parameters:
Diffie-Hellman Modulus (p): 575e67ece4e0a0b76fd457621dca50b3fd631
c7d622105a3461865da39a42ffb
Diffie-Hellman Generator (g): 6b4b0d3255bfef95601890afd8070994
Subject Public Key: Diffie-Hellman public value = 3bf531a6602
de246927003d0121d57d9cf089dbafcc99e65524d40adf73b12aa
</PRE>
<P>A variety of recognized standards are associated with such certificates. The information content is defined in the X.509 specification. Actual formats for conveying certificates are defined in the Public Key Cryptography Specifications (PKCS). The specification PKCS #10 defines the format for requesting a certificate from a CA and the specification PKCS #7 defines the format for the certificate issued by the CA.
</P>
<H4 ALIGN="LEFT"><A NAME="Heading20"></A><FONT COLOR="#000077">Authorization</FONT></H4>
<P>Once the identity of an entity is established through some authentication procedure, what that entity is allowed to do in the context of a given system is the subject of another security concept termed <I>authorization</I>. It is useful to think of authorization in the context of a server that is being accessed by a client. The server provides information or some other abstract service to the client, based on what privileges the client has with respect to that server. The model is illustrated in Figure 9.6.</P>
<P><A NAME="Fig6"></A><A HREF="images/09-06.jpg"><IMG SRC="images/09-06t.jpg"></A>
<BR><A HREF="images/09-06.jpg"><FONT COLOR="#000077"><B>Figure 9.6.</B></FONT></A> The authorization model.</P>
<P>This model indicates that if a client wants to gain some type of access to an object of interest, it must first authenticate its identity to the server. The server can then consult a list of privileges that the client (identity) has with respect to that object of interest. The figure denotes this list of privileges as an access control list (ACL); most such mechanisms can be abstracted back to something that looks like an ACL. This mechanism is widely used within smart cards for access to information (in files or objects) or processing capabilities (functions).
</P>
<P><FONT SIZE="+1"><B>Access Control Lists</B></FONT></P>
<P>Access control lists are authorization or privileges lists which link identities, and what those identities are allowed to do, to specific objects of interest. The ACL is typically viewed from the perspective of the object of interest and the server that makes that object of interest accessible to clients. It is the server that interprets the ACL and decides, based on the authorizations it finds there, what access to allow to the object of interest by the client. For a particular object of interest, a well-defined set of authorizations can typically be defined. For a file, for instance, the following privileges are typically defined:
</P>
<DL>
<DD><B>•</B> Create
<DD><B>•</B> Delete
<DD><B>•</B> Read
<DD><B>•</B> Write
<DD><B>•</B> Modify
<DD><B>•</B> Execute
</DL>
<P>An ACL for such a file might then look as shown in Table 9.1.
</P>
<TABLE WIDTH="100%"><CAPTION ALIGN=LEFT><B>Table 9.1.</B> The access control list for the file <TT>abc.txt</TT>.
<TR>
<TH WIDTH="25%" ALIGN="LEFT">Identity
<TH WIDTH="12%" ALIGN="LEFT">Create
<TH WIDTH="13%" ALIGN="LEFT">Delete
<TH WIDTH="12%" ALIGN="LEFT">Read
<TH WIDTH="12%" ALIGN="LEFT">Write
<TH WIDTH="13%" ALIGN="LEFT">Execute
<TH WIDTH="13%" ALIGN="LEFT">Control
<TR>
<TD COLSPAN="7"><HR>
<TR>
<TD>Jane Doe
<TD>×
<TD>×
<TD>×
<TD>×
<TD>×
<TD>×
<TR>
<TD>Good Person
<TD>
<TD>
<TD>×
<TD>×
<TD>×
<TR>
<TD>Iffy Person
<TD>
<TD>
<TD>
<TD>×
<TR>
<TD COLSPAN="7"><HR>
</TABLE>
<P>This ACL says that the identity Jane Doe can do anything at all to the file. The identity Good Person can read, write, and execute any code found in the file while the identity Iffy Person can only read the contents of the file.
</P><P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="214-216.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="219-221.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
</BODY></HTML>
?? 快捷鍵說明
復(fù)制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號(hào)
Ctrl + =
減小字號(hào)
Ctrl + -