Mercurial Mercurial > oss > FCL > sf > os > security / diff
summary | shortlog | changelog | graph | tags | bookmarks | branches | files | changeset | file | latest | revisions | annotate | diff | comparison | raw | help
Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
cryptomgmtlibs/securitydocs/Security_Glossary.html
changeset 60 11c66574c2a2
parent 56 c11c717470d0
child 62 b23410e29e22
child 65 970c0057d9bc 
--- a/cryptomgmtlibs/securitydocs/Security_Glossary.html	Fri Apr 16 16:52:34 2010 +0300
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,718 +0,0 @@
-<HTML>
-<HEAD>
-<TITLE>Security Glossary</TITLE>
-</HEAD>
-<BODY>
-
-<H1><CENTER><b>Security Glossary</b></CENTER></H1>
-
-<P><center><TABLE WIDTH="90%" BORDER="1" CELLSPACING="1" CELLPADDING="2"><TR
-HEIGHT=0>
-<TD WIDTH="25%"></TD><TD WIDTH="75%"></TD></TD>
-</TR>
-
-<TR>
-<TD>
-Security Classification
-</td>
-<td>
-Internal
-</td>
-</tr>
-
-<TR>
-<TD>
-Document Reference
-</td>
-<td>
-SGL.GT0128.56
-</td>
-</tr>
-
-<TR>
-<TD>
-Status
-</td>
-<td>
-Draftversion
-</td>
-</tr>
-
-<TR>
-<TD>
-Version
-</td>
-<td>
-0.1
-</td>
-</tr>
-	
-<TR>
-<TD>
-Team/Department
-</td>
-<td>
-Security Team
-</td>
-</tr>
-
-<TR>
-<TD>
-Author
-</td>
-<td>
-William Bamberg
-</td>
-</tr>
-
-<TR>
-<TD>
-Owner
-</td>
-<td>
-Security Team
-</td>
-</tr>
-
-<TR HEIGHT=0><TD WIDTH="35%"></TD><TD
-WIDTH="65%"></TD></TR></TABLE></P></center>
-
-<P><center><TABLE WIDTH="90%" BORDER="1" CELLSPACING="1" CELLPADDING="2"><TR
-HEIGHT=0>
-<TD WIDTH="25%"></TD><TD WIDTH="75%"></TD></TD>
-</TR>
-
-<TR>
-<TD>
-<A name="Asymmetric Cryptography"></A>Asymmetric Cryptography
-</td>
-<td>
-A form of cryptography in which the 'key' is generated as a key pair: if one key is used for encryption
-only the other can be used to decrypt, and vice versa.
-<p>
-Using asymmetric cryptography, the problem of key distribution becomes one of authentication; i.e. how to make sure
-that a given key really does belong to the entity that claims to own it.
-</td>
-</tr>
-
-<TR>
-<TD>
-Attribute Certificate
-</td>
-<td>
-A digitally signed data structure including at least an identifier for an individual entity 
-and a set of attributes, whose function is to bind the entity with the attributes, usually for the
-purpose of authorisation.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Authentication"></A>Authentication
-</td>
-<td>
-Usually used to refer to a property of a communication; that the receiver of a message is able to ascertain its origin,
-so an attacker cannot successfully impersonate the sender.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Block Cipher"></A>Block Cipher
-</td>
-<td>
-A class of <A HREF="#Symmetric Cryptography">symmetric algorithm</A> in which several bits of the input data 
-are encrypted at once in a fixed-size block. 
-The cipher and its mode of operation define the block size: 
-the plaintext is split up into appropriately-sized blocks and each block is fed into the cipher. 
-</td>
-</tr>
-
-<TR>
-<TD>
-CA Certificate
-</td>
-<td>
-A certificate held by a <A HREF="#Certification Authority">CA</A>: the key pair associated with it is used for 
-signing certificates issued by that CA. May or may not be self-signed.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Certificate"></A>Certificate
-</td>
-<td>
-For our purposes, this is the same thing as a <A HREF="#Public Key Certificate">
-public key certificate</A>
-</td>
-</tr>
-
-<TR>
-<TD><A name="Certification Authority"></A>Certification Authority (CA)
-</td>
-<td>
-An organization which perform the following functions in a hierachical <A HREF="#Public Key Infrastructure">PKI</A>:
-<ul>
-<li>
-providing trusted ‘root’ certificates to users (<A HREF="#End Entities">End Entities</A>), by 
-supplying them with the CA’s public key via out-of-band means.
-</li>
-<li>
-certifying End Entities by generating and distributing certificates for them. 
-The certified EE is the subject of the certificate: the CA is the issuer.
-</li>
-<li>
-supporting certificate <A HREF="#Revocation">revocation</A> and revocation checking: if an EE suspects that their key has 
-been compromised, they contact the CA which issued it, who should revoke their certificate.
-</li>
-</ul>
-<p>A CA will always have a root certificate-signing key pair, which must be authenticated to End Entities via
-out of band channels. This key pair is not logically certified by anything, but it is usually distributed inside 
-a <A HREF="#Self-signed Certificate">self-signed certificate</A> to afford some degree of <A HREF="#Tamper Evidency">tamper evidency</A>. 
-<p>However, CAs do not have to use their root key pair to issue certificates directly to End Entities. For organizational 
-reasons and to reduce the exposure of keys, a CA may have a single root signing key pair, which it uses to certify a 
-set of subordinate key pairs, which in turn are used to certify End Entities. Also, CAs may certify the 
-signing keys of other CAs by issuing <A HREF="#Cross Certificate">cross certificates</A>, which enable interoperation 
-between two distinct PKIs.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Ciphertext"></A>Ciphertext
-</td>
-<td>
-The output of an <A HREF="#Encryption">encryption</A> operation, or 
-the input to a <A HREF="#Decryption">decryption</A> operation.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Client Authentication"></A>Client Authentication
-</td>
-<td>
-In a secure client-server protocol such as <A HREF="#Transport Layer Security">TLS</A>, the process in which the client
-<A HREF="#Authentication">authenticates</A> itself to the server, so the server knows who it's talking to.
-</td>
-</tr>
-
-<TR>
-<TD>
-Client/User/End Entity Certificate
-</td>
-<td>
-A <A HREF="#Certificate">certificate</A> issued by a <A HREF="#Certification Authority">CA</A> to an 
-<A HREF="#End Entity">end entity</A> (for example the user of a WID) who may use it 
-to demonstrate their ownership of the key pair associated with it
-</td>
-</tr>
-
-
-<TR>
-<TD>
-<A name="Cross Certificate"></A>Cross Certificate
-</td>
-<td>
-A <A HREF="#Certificate">certificate</A> issued by a <A HREF="#Certification Authority">CA</A> which certificates another
-CA's <A HREF="#Root Certificate">root certificate</A>. This is way of uniting two distinct certification hierarchies. 
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Decryption"></A>Decryption
-</td>
-<td>
-The process of turning encrypted data (called ciphertext) into the original information (called plaintext)
-using a cryptographic algorithm parameterised with a key.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Digital Signature"></A>Digital Signature
-</td>
-<td>
-A structure linking some data and a private key. A digital signature may be generated by the application of a 
-<A HREF="#Private Key">private key</A> to some piece of data. The original data 
-may be reconstructed by applying the corresponding public key, demonstrating that the signature could only have been generated by 
-someone with access to the private key. 
-<p>Digital signatures have two primary uses: to demonstrate someone's identity by signing some challenge, as in 
-<A HREF="#Client Authentication">client authentication</A> in <A HREF="#Transport Layer Security">TLS</A>, in which the client 
-signs a <A HREF="#Hash">hash</A> of the messages that have been exchanged, and more strongly, for someone to demonstrate their
-acceptance of some human-processable information (e.g. 'Please withdraw £10 000 from my bank account') as in the
-<A HREF="#WMLScript Crypto API">WMLScript Crypto API</A> <A HREF="#SignText">SignText</A> function.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="DSA"></A>Digital Signature Algorithm (DSA)
-</td>
-<td>
-NIST-approved <A HREF="#Asymmetric Cryptography">asymmetric algorithm</A>. It can only be used for generating and
-verifying <A HREF="#Digital Signature">digital signatures</A>, not for encryption. 
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="ECC"></A>Elliptic Curve Cryptography (ECC)
-</td>
-<td>
-Elliptical curve cryptography (ECC) is an <A HREF="#Asymmetric Cryptography">asymmetric algorithm</A>
- based on elliptic curve theory that can be used to create faster, smaller, and more efficient cryptographic keys. 
-Because ECC helps to establish equivalent security with lower computing power and battery resource usage, 
-it is becoming widely used for mobile applications.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Encryption"></A>Encryption
-</td>
-<td>
-The process of turning meaningful data (called plaintext) into meaningless gibberish (called ciphertext)
-using a cryptographic algorithm parameterised with a key.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="End Entity"></A>End Entity
-</td>
-<td>
-A leaf node in a certification hierarchy: any entity in a <A HREF="#Public Key Infrastructure">PKI</A>
-which has a certificate, but is not allowed to issue its own certificates.
-</td>
-</tr>
-
-
-<TR>
-<TD>
-<A name="Hash"></A>Hash
-</td>
-<td>
-Hash algorithms take a variable-length input and produce a fixed length output known as a digest, or hash, of the input. 
-For cryptographic purposes they need to be one-way functions: 
-it should not be possible to deduce the input from the digest, or even any part of the input.
- Also, it should be hard to find collisions: that is, two different inputs which produce the same output.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="HMAC"></A>HMAC
-</td>
-<td>
-Keyed-Hashing for Message Authentication. A mechanism for message authentication using cryptographic 
-<A HREF="#Hash">hashes</A>. It can be used with any iterative cryptographic 
-hash function, e.g., <A HREF="#MD5">MD5</A>, <A HREF="#SHA-1">SHA-1</A>, in combination with a secret shared key.  
-The cryptographic strength of HMAC depends on the properties of the underlying hash function.
-</td>
-</tr>
-
-<TR>
-<TD>
-ICC
-</td>
-<td>
-Integrated Circuit Card: removable card with at least data storage and sometimes processing 
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="IPSec"></A>IPSec
-</td>
-<td>
-A standard providing <A HREF="#Secrecy">secrecy</A> and <A HREF="#Authentication">authentication</A> at the network or 
-packet-processing layer of network communication. Earlier security approaches have inserted security at the 
-application layer of the communications model. IPsec will be especially useful for implementing virtual 
-private networks and for remote user access through dial-up connection to private networks. IPSec is mandatory in IPv6.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="MD2"></A>MD2
-</td>
-<td>
-Legacy <A HREF="#Hash">hash algorithm</A>. Considered insecure.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="MD5"></A>MD5
-</td>
-<td>
-Legacy <A HREF="#Hash">hash algorithm</A>. Considered vulnerable.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Message Digest Algorithm"></A>Message Digest Algorithm
-</td>
-<td>
-Same thing as a <A HREF="#Hash">hash algorithm</A>.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Nonrepudiation"></A>Nonrepudiation
-</td>
-<td>
-The process by which it is assured that an entity making a declaration cannot subsequently deny having made it: 
-so I can't claim that I never wrote that cheque. 
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="OCSP"></A>Online Certificate Status Protocol (OCSP)
-</td>
-<td>
-A protocol enabling a <A HREF="#Relying Party">relying party</A> to check that a 
-<A HREF="#Certificate">certificate</A> has not been <A HREF="#Revocation">revoked</A>. In this protocol the OCSP client 
-asks the OCSP server about the status of one or more certificates, and receives a 
-<A HREF="#Digital Signature">digitally signed</A> response. 
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Out Of Band"></A>Out Of Band
-</td>
-<td>
-A channel of communication which is distinct from the channel which we are using cryptography to try to secure,
-and which is secure on its own terms; that is, its security is not dependent on the cryptography we are using.
-<p>A common example of an out of band channel is a motorcycle courier. 
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Padding"></A>Padding
-</td>
-<td>
-The process of adding bytes to the input to a <A HREF="#Block Cipher">block cipher</A> so that the input matches the
-block size.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Plaintext"></A>Plaintext
-</td>
-<td>
-The output of an <A HREF="#Decryption">decryption</A> operation, or 
-the input to a <A HREF="#Encryption">encryption</A> operation.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="PGP"></A>Pretty Good Privacy (PGP)
-</td>
-<td>
-A very widely-used <A HREF="#Encryption">encryption</A> and <A HREF="#Digital Signature">digital signing</A>
-program.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Private Key"></A>Private Key
-</td>
-<td>
-In the context of <A HREF="#Public Key Cryptography">public key cryptography</A>, the private half of the key pair.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Public Key"></A>Public Key
-</td>
-<td>
-In the context of <A HREF="#Public Key Cryptography">public key cryptography</A>, the public half of the key pair.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Public Key Certificate"></A>Public Key Certificate
-</td>
-<td>
-A digitally signed structure including at least an identifier for an 
-individual entity and a public key, whose function is to bind the entity with the key.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Public Key Cryptography"></A>Public Key Cryptography
-</td>
-<td>
-A common application of <A HREF="#Asymmetric Cryptography">asymmetric cryptography</A> in which one half of the key pair is
-kept secrect (the <A HREF="#Private Key">private key</A>) and the other half is published 
-(the <A HREF="#Public Key">public key</A>.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Public Key Infrastructure"></A>Public Key Infrastructure
-</td>
-<td>
-
-<p>A way of modelling real-world trust relationships which enables users of <A HREF="#Public Key Cryptography">public key cryptography</A> 
-to have confidence in the ownership of
-the public keys they are using.  
-
-A PKI consists of:
-<ul>
-<li>
-a <A HREF="#Trusted Third Party">trusted third party</a> 
-</li>
-<li>
-an <A HREF="#Out Of Band">out of band</A>  means of distributing the TTP's <A HREF="#Public Key Certificate">public key certificate</A> 
-to <A HREF="#Relying Party">relying parties</a>
-</li>
-<li>
-a means of distributing other certificates to relying parties
-</li>
-<li>
-arrangements for the <A HREF="#Revocation">revocation</A> and renewal of these certificates
-</li>
-<li>
-certificate management and validation software on the relying party's computer
-</li>
-</ul>
-<p>The TTP uses its signing key pair to create certificates for other entities, which relying parties can use to authenticate these
-other entities.
-<p>We can classify PKIs according to whether they are hierachical or flat. In hierachical PKIs, such as the one defined in the <A HREF="#PKIX">PKIX</A> 
-set of standards, there is a distinction between users of the PKI such as <A HREF="#End Entity">End Entities</A> and 
-<A HREF="#Relying Party">Relying Parties</A>, and entities responsible for issuing and distributing certificates such as 
-<A HREF="#Certification Authority">CAs</A> and <A HREF="#Registration Authority">RAs</A>. In a flat PKI such as the 
-<A HREF="#Web of Trust">web of trust</A> underpinning <A HREF="#Pretty Good Privacy">PGP</A>, there are no entities whose
-sole role is to issue certificates; instead users of the PKI certify each other.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Registration Authority"></A>Registration Authority
-</td>
-<td>
-An organization responsible for registering new certificate users in a 
-<A HREF="#Public Key Infrastructure">PKI</A>, e.g. by gathering and verifying information which identifies the 
-certificate applicant.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Revocation"></A>Revocation
-</td>
-<td>
-The term used for asserting that a certificate is no longer valid: for example, because the private key 
-associated with it has been compromised.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Relying Party"></A>Relying Party
-</td>
-<td>
-An entity who relies on the authenticity of a <A HREF="#Public Key">public key</a>.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Root Certificate"></A>Root Certificate
-</td>
-<td>
-The certificate of a <A HREF="#Trusted Third Party">trusted third party</a>.  
-A certificate directly trusted by a <A HREF="#Relying Party">relying party</A>: that is, trust in it is not 
-established by cryptographic means, but trust in it is the prerequisite for establishing trust in the entity 
-which the relying party is trying to authenticate. 
-Trust in a root certificate must be established through <A HREF="#Out Of Band">out of band</A> means. A root certificate may or may not be self signed.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Secrecy"></A>Secrecy
-</td>
-<td>
-This means that access to information is controlled: for example, it means that two entities 
-(e.g. people, machines, processes) are able to communicate with one another without any other entities 
-being able to access the information communicated, or that an entity may store some information and be 
-assured that only this entity will be able to access it. 
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="SHA-1"></A>Secure Hash Algorithm 1(SHA-1)
-</td>
-<td>
-A widely used <A HREF="#Hash">hash algorithm</a>, producing a 160-bit digest.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="SSL"></A>Secure Sockets Layer (SSL)
-</td>
-<td>
-Precursor to <A HREF="#Transport Layer Security">TLS</a>. SSL has been through three versions:
-the first two are considered insecure, and the third is almost identical to TLS. 
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Server Authentication"></A>Server Authentication
-</td>
-<td>
-In a secure client-server protocol such as <A HREF="#Transport Layer Security">TLS</A>, the process in which the server
-<A HREF="#Authentication">authenticates</A> itself to the client, so the client knows who it's talking to.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="SignText"></A>SignText
-</td>
-<td>
-A function defined in the <A HREF="#WMLScript Crypto API">WMLScript Crypto API</A> which provides application-level
-<A HREF="#Authentication">Authentication</A> and <A HREF="#Nonrepudiation">Nonrepudiation</A> for transactions.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Stream Cipher"></A>Stream Cipher
-</td>
-<td>
-A class of <A HREF="#Symmetric Cryptography">symmetric algorithm</A> which is initialised with a key,
-then outputs a stream of pseudorandom bits. 
-This 'keystream' is typically XOR-ed with the plaintext to generate the ciphertext. 
-So they encrypt a bit of plaintext at a time.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Symmetric Cryptography"></A>Symmetric Cryptography
-</td>
-<td>
-A form of cryptography in which the same key is used for encryption and decryption
-<p>
-Symmetric cryptography is fast, but suffers from the problem of how to distribute the key privately.
-<A HREF="#Asymmetric Cryptography">Asymmetric cryptography</a> is an attempt to alleviate the key
-distribution problem, by reducing the requirement for the distributed key from one of privacy to one of
-authentication.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Transport Layer Security"></A>Transport Layer Security (TLS)
-</td>
-<td>
-A client-server security protocol providing <A HREF="#Secrecy">secrecy</a> and optionally <A HREF="#Authentication">authentication</a>, and 
-running over TCP/IP. 
-<p>In this protocol a client connects to a server; the two then perform a handshake in which they exchange a 
-<A HREF="#Symmetric Cryptography">symmetric</a> key by using <A HREF="#Asymmetric Cryptography">asymmetric cryptography</a>, 
-which is then used to encrypt their communications, providing the secrecy element. 
-<p>Without the authentication element secrecy is not very useful; although only client and server can understand the data 
-exchanged, the client doesn't know who the server is or vice versa. TLS provides the capability for 
-<A HREF="#Server Authentication">server authentication</a>, in which the client establishes who the server is, and 
-<A HREF="#Client Authentication">client authentication</a> in which the server establishes who the client is. 
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Trusted Third Party"></A>Trusted Third Party (TTP)
-</td>
-<td>
-An entity whose public key is known to a <A HREF="#Relying Party">relying party</a> due to its having been 
-received via <A HREF="#Out Of Band">out of band</A> means, and which is trusted to issue <A HREF="#Public Key Certificate">
-public key certificates</A> for other entities not directly known to the relying party.
-<p>A  <A HREF="#Certification Authority">CA</a> is a type of TTP.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="Web of Trust"></A>Web of Trust
-</td>
-<td>
-The set of social relationships between users of <A HREF="#PGP">PGP</a> that enables them to sign each others' keys, 
-essentially providing a <A HREF="#PKI">PKI</a> for this technology.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="WMLScript Crypto API"></A>WMLScript Crypto API
-</td>
-<td>
-A WAP Forum standard which defines cryptographic functions in WML, the scripting language used in WAP. 
-It defines a function for creating signed objects called <A HREF="#SignText">SignText</a>
-</td>
-</tr>
-
-
-<TR>
-<TD>
-<A name="WTLS"></A>WTLS
-</td>
-<td>
-A client-server security protocol providing <A HREF="#Secrecy">secrecy</a> and optionally <A HREF="#Authentication">authentication</a>, 
-running at the transport layer of the WAP stack. WTLS is closely modelled on <A HREF="#Transport Layer Security">TLS</a>, 
-and defines its own lightweight <A HREF="#Public Key Certificate">certificate</a> format.
-</td>
-</tr>
-
-<TR>
-<TD>
-<A name="X.509 Certificate"></A>X.509 Certificate
-</td>
-<td>
-A widely used type of <A HREF="#Public Key Certificate">public key certificates</A>, part of the
-now largely moribund X.500 series of standards.
-</td>
-</tr>
-
-<!--
-<TR><TD><A HREF="/rfc2459">RFC 2459</a></td>
-<td>PKIX Certificate and CRL Profile<br>
-<b>This RFC is being updated by two new Internet draftversions,
-<a href="/draftversion-ietf-pkix-new-part1">draftversion-ietf-pkix-new-part1</a>
-and <a href="/draftversion-ietf-pkix-ipki-pkalgs">draftversion-ietf-pkix-ipki-pkalgs</a>.</b>
-</td>
-</tr>
--->
-
-<!--
-<TR><TD><A
-HREF="/draftversion-ramsdell-role-names">draftversion-ramsdell-role-names</A></TD><TD>Role
-Names in X.509 Certificates</TD>
-<TD>Expired</TD></TR>
--->
-
-<TR HEIGHT=0><TD WIDTH="35%"></TD><TD
-WIDTH="65%"></TD></TR></TABLE></P></center>
-
-</BODY></HTML>
FCL/sf/os/security