--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/cryptomgmtlibs/securitydocs/Security_Glossary.html Wed Jul 08 11:25:26 2009 +0100
@@ -0,0 +1,718 @@
+<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>