1 /** |
|
2 @page security_glossary Security glossary |
|
3 \n |
|
4 A glossary of security terms (mostly non-Symbian specific). |
|
5 \n\n |
|
6 @ref A, @ref B, @ref C, @ref D, @ref E, @ref F, @ref G, @ref H, @ref I, @ref J, @ref K, @ref L, @ref M, @ref N, @ref O, |
|
7 @ref P, @ref Q, @ref R, @ref S, @ref T, @ref U, @ref V, @ref W, @ref X, @ref Y, @ref Z |
|
8 \n @anchor A \n |
|
9 |
|
10 <table> |
|
11 |
|
12 <tr><td><b>A</b></td><td></td></tr> |
|
13 |
|
14 <tr><td>@anchor AES AES</td> |
|
15 <td>Advanced Encryption Standard -- The new conventional symmetric @ref block_cipher "block cipher" chosen by NIST as a |
|
16 replacement for @ref DES. It can process 128-bit data blocks using |
|
17 cipher keys with lengths of 128, 192, or 256 bits.</td></tr> |
|
18 |
|
19 <tr><td>@anchor ASN ASN.1</td> |
|
20 <td>Abstract Syntax Notation 1 (See: <A HREF="http://asn1.elibel.tm.fr/en/introduction/index.htm">ASN.1</A>, |
|
21 ISO/IEC 8824, and ISO/IEC 8825.) -- A data specification meta-language widely used in @ref public_key_cryptography "public key cryptography" |
|
22 standards. (Also of interest: <A HREF="ftp://ftp.rsasecurity.com/pub/pkcs/doc/layman.doc">A Layman's Guide to |
|
23 a Subset of ASN.1, BER, and DER</A>.)</td></tr> |
|
24 |
|
25 <tr><td>@anchor asymmetric @anchor Asymmetric Asymmetric Cryptography</td> |
|
26 <td>A form of cryptography in which the 'key' is generated as a key pair: if one key is used for @ref encryption only the |
|
27 other can be used to decrypt, and vice versa. \n\n |
|
28 Using asymmetric cryptography, the problem of key distribution becomes one of @ref authentication; i.e. how to make sure |
|
29 that a given key really does belong to the entity that claims to own it. See: |
|
30 @li @ref asymmetric_cryptography |
|
31 @li @ref SS_Cryptalg_asymmetric_ciphers.</td></tr> |
|
32 |
|
33 <tr><td>@anchor attribute_cert Attribute Certificate</td> |
|
34 <td>A digitally signed data structure including at least an identifier for an individual entity and a set of |
|
35 attributes, whose function is to bind the entity with the attributes, usually for the purpose of authorisation. |
|
36 </td></tr> |
|
37 |
|
38 <tr><td>@anchor authentication @anchor Authentication Authentication</td> |
|
39 <td>Usually used to refer to a property of a communication; that the receiver of a message is able to ascertain its |
|
40 origin, so an attacker cannot successfully impersonate the sender. </td></tr> |
|
41 |
|
42 |
|
43 |
|
44 </table>\n @anchor B \n<table> |
|
45 |
|
46 <tr><td><b>B</b></td><td></td></tr> |
|
47 |
|
48 <tr><td>@anchor BER BER</td> |
|
49 <td>Basic Encoding Rules for @ref ASN "ASN.1", as defined in X.690. (Also of interest: |
|
50 <A HREF="ftp://ftp.rsasecurity.com/pub/pkcs/doc/layman.doc">A Layman's Guide to a Subset of ASN.1, BER, and DER</A>.) |
|
51 </td></tr> |
|
52 |
|
53 <tr><td>@anchor block_cipher Block Cipher</td> |
|
54 <td>A class of symmetric algorithm in which several bits of the input data are encrypted at once in a fixed-size |
|
55 block. The cipher and its mode of operation define the block size: the @ref plaintext is split up into appropriately-sized |
|
56 blocks and each block is fed into the cipher. </td></tr> |
|
57 |
|
58 |
|
59 |
|
60 </table>\n @anchor C \n<table> |
|
61 |
|
62 <tr><td><b>C</b></td><td></td></tr> |
|
63 |
|
64 <tr><td>@anchor CA CA</td> |
|
65 <td>Certification Authority -- An organisation that performs the following functions in a hierachical @ref PKI: |
|
66 @li providing trusted @ref root_certificate "'root' certificates" to users (@ref EE "End Entities"), by supplying them with the CA's @ref public_key "public key" via |
|
67 out-of-band means. |
|
68 @li certifying End Entities (@ref EE "EE"s) by generating and distributing certificates for them. The certified @ref EE is the |
|
69 subject of the @ref certificate; the CA is the issuer. The CA validates the certificate holder's identity and 'signs' |
|
70 the @ref certificate so that it cannot be tampered with or forged. The @ref certificate issued by the CA binds a particular |
|
71 @ref public_key "public key" to the name of the @ref EE the @ref certificate identifies. |
|
72 @li supporting certificate revocation and revocation checking: if an @ref EE suspects that their key has been compromised, |
|
73 they can contact the CA that issued it, who will then revoke their @ref certificate. |
|
74 |
|
75 A CA will always have a root certificate-signing key pair that must be authenticated to End Entities via @ref out_of_band "out of band" |
|
76 channels. This key pair is not logically certified by anything, but it is usually distributed inside a self-signed |
|
77 @ref certificate to afford some degree of tamper evidency. \n\n |
|
78 However, CAs do not have to use their root key pair to issue certificates directly to End Entities. For organizational |
|
79 reasons and to reduce the exposure of keys, a CA may have a single root signing key pair, which it uses to certify a |
|
80 set of subordinate key pairs that in turn are used to certify End Entities. Also, CAs may certify the signing keys |
|
81 of other CAs by issuing cross certificates, which enable interoperation between two distinct @ref PKI "PKI"s.</td></tr> |
|
82 |
|
83 <tr><td>@anchor CA_certificate CA Certificate |
|
84 <td>A @ref certificate held by a @ref CA: the key pair associated with it is used for signing certificates issued by that |
|
85 @ref CA. May or may not be self-signed.</td></tr> |
|
86 |
|
87 <tr><td>@anchor CBC CBC</td> |
|
88 <td>Cipher Block Chaining -- A cryptographic mode for @ref block_cipher "block ciphers". It is an @ref encryption method that protects |
|
89 against block replay attacks by making the encryption of a cipher block dependent on all blocks that precede it. |
|
90 Before it is encrypted, the @ref plaintext is XORed with the previous @ref ciphertext block (which has been stored in a |
|
91 feedback register). After the encryption, the resulting ciphertext is again stored in the feedback register, to |
|
92 be XORed with the next plaintext block, and so on until the end of the message.</td></tr> |
|
93 |
|
94 <tr><td>@anchor certificate @anchor certificates Certificate</td> |
|
95 <td>For our purposes, this is the same thing as a @ref public_key_certificate "public key certificate".</td></tr> |
|
96 |
|
97 <tr><td>@anchor ciphermode Ciphermode</td> |
|
98 <td> description</td></tr> |
|
99 |
|
100 <tr><td>@anchor ciphertext Ciphertext</td> |
|
101 <td>The output of an @ref encryption operation, or the input to a @ref decryption operation.</td></tr> |
|
102 |
|
103 <tr><td>@anchor CLDC CLDC</td> |
|
104 <td><A HREF="http://java.sun.com/products/cldc/">J2ME Connected Limited Device Configuration</A> -- Serves the market consisting of personal, mobile, and |
|
105 connected information devices. This configuration includes some new classes designed specifically to fit the |
|
106 needs of small-footprint devices.</td></tr> |
|
107 |
|
108 <tr><td>@anchor client_authentication Client Authentication</td> |
|
109 <td>In a secure client-server protocol such as @ref TLS, the process in which the client authenticates itself to |
|
110 the server, so the server knows who it's talking to. \n See @ref WTLS_client_authentication "client authentication in WTLS". </td></tr> |
|
111 |
|
112 <tr><td>Client/User/End Entity Certificate</td> |
|
113 <td>A @ref certificate issued by a @ref CA to an end entity, @ref EE, who may use it to demonstrate their |
|
114 ownership of the key pair associated with it.</td></tr> |
|
115 |
|
116 <tr><td>@anchor CRL CRL</td> |
|
117 <td>Certificate Revocation List -- A list of (identifiers for) @ref certificates that have been revoked by a |
|
118 particular @ref CA. The use of CRLs is for maintaining access to servers in a network, in a @ref PKI; in some cases, |
|
119 @ref OCSP has superseded CRL. See: |
|
120 @li <A HREF="http://www.ietf.org/rfc/rfc2459.txt">RFC2459</A> |
|
121 -- Internet @ref X509 "X.509" @ref PKI Certificate and CRL Profile |
|
122 @li <A HREF="http://www.ietf.org/rfc/rfc3279.txt">RFC3279</A> |
|
123 -- Algorithms and Identifiers for the Internet @ref X509 "X.509" @ref PKI Certificate and Certificate Revocation List |
|
124 (@ref CRL) Profile |
|
125 @li <A HREF="http://www.ietf.org/rfc/rfc3280.txt">RFC3280</A> |
|
126 -- Internet @ref X509 "X.509" @ref PKI Certificate and Certificate Revocation List (@ref CRL) Profile. |
|
127 </td></tr> |
|
128 |
|
129 <tr><td>@anchor cross_certificate Cross Certificate</td> |
|
130 <td>A @ref certificate issued by a @ref CA which certificates another @ref CA's @ref root_certificate "root certificate". This is way of uniting two distinct |
|
131 certification hierarchies.</td></tr> |
|
132 |
|
133 |
|
134 |
|
135 </table>\n @anchor D \n<table> |
|
136 |
|
137 <tr><td><b>D</b></td><td></td></tr> |
|
138 |
|
139 <tr><td>@anchor decryption Decryption</td> |
|
140 <td>The process of turning encrypted data (called @ref ciphertext) into the original information (called |
|
141 @ref plaintext) using a cryptographic algorithm parameterised with a key.</td></tr> |
|
142 |
|
143 <tr><td>@anchor DER DER</td> |
|
144 <td>Distinguished Encoding Rules -- A set of rules for encoding @ref ASN "ASN.1" data structures as a byte stream, which |
|
145 has the property that any given @ref ASN "ASN.1" data structure will always encode to the same byte stream. DER is a |
|
146 subset of @ref BER. (Also of interest: |
|
147 <A HREF="ftp://ftp.rsasecurity.com/pub/pkcs/doc/layman.doc">A Layman's Guide to a Subset of ASN.1, BER, and DER</A>.) |
|
148 </td></tr> |
|
149 |
|
150 <tr><td>@anchor DES DES</td> |
|
151 <td>Data Encryption Standard -- A symmetric @ref block_cipher "block cipher" (that is the U.S. and international standard) used for |
|
152 @ref encryption and @ref decryption. A 64-bit block cipher with a 56-bit key organized as 16 rounds of operations. </td></tr> |
|
153 |
|
154 <tr><td>@anchor digital_signature Digital Signature</td> |
|
155 <td>A structure linking some data and a @ref private_key "private key". A digital signature may be generated by the application of a |
|
156 private key to some piece of data. The original data may be reconstructed by applying the corresponding @ref public_key "public key", |
|
157 demonstrating that the signature could only have been generated by someone with access to the private key.\n\n |
|
158 Digital signatures have two primary uses: to demonstrate someone's identity by signing some challenge, as in |
|
159 @ref client_authentication "client authentication" in @ref TLS, in which the client signs a @ref hash of the messages that have been exchanged; |
|
160 and more strongly, for someone to demonstrate their acceptance of some human-processable information (e.g. |
|
161 'Please withdraw £10,000 from my bank account') as in the @ref WMLScript Crypto API SignText function.\n\n |
|
162 See: an introduction to @ref Security_signatures.</td></tr> |
|
163 |
|
164 <tr><td>@anchor DN DN</td> |
|
165 <td>Distinguished Name -- An @ref ASN "ASN.1" structure containing various attributes (name-value pairs) that together |
|
166 uniquely identify the entity for certification purposes. \n\n |
|
167 The name used in @ref X509_certificate "X.509 certificates" is the X.500 Distinguished Name, which describes a path |
|
168 through an X.500 Directory Information Tree. Conventionally, a DN comprises <i> at least </i> three attributes: a user's |
|
169 name/ID (e.g., \c cn=Fred \c Bloggs), an organization name (e.g., \c o=Symbian \c UK \c Ltd), and a country designation |
|
170 (e.g., \c c=GB ). |
|
171 </td></tr> |
|
172 |
|
173 <tr><td>@anchor DSA DSA</td> |
|
174 <td>Digital Signature Algorithm -- A NIST-approved @ref asymmetric algorithm. It can only be used for generating |
|
175 and verifying @ref digital_signature "digital signatures", not for @ref encryption. |
|
176 See: The <A HREF="http://www.itl.nist.gov/fipspubs/fip186.htm">Digital Signature Standard</A>. |
|
177 </td></tr> |
|
178 |
|
179 |
|
180 |
|
181 </table>\n @anchor E \n<table> |
|
182 |
|
183 <tr><td><b>E</b></td><td></td></tr> |
|
184 |
|
185 <tr><td>@anchor ECB ECB</td> |
|
186 <td>Electronic Codebook -- A cryptographic mode for @ref block_cipher "block ciphers". It is a mode that encrypts |
|
187 blocks of @ref plaintext to corresponding blocks of @ref ciphertext. Given use of the same key, a block of plaintext |
|
188 will always encrypt to the same block of ciphertext.</td></tr> |
|
189 |
|
190 <tr><td>@anchor ECC ECC</td> |
|
191 <td>Elliptical Curve Cryptography -- An @ref asymmetric @ref encryption technique based on elliptic curve theory that |
|
192 can be used to create faster, smaller, and more efficient cryptographic keys.</td></tr> |
|
193 |
|
194 <tr><td>@anchor encryption Encryption</td> |
|
195 <td>The process of turning meaningful data (called @ref plaintext) into meaningless gibberish (called @ref ciphertext) |
|
196 using a cryptographic algorithm parameterised with a key.</td></tr> |
|
197 |
|
198 <tr><td>@anchor EE EE</td> |
|
199 <td>End Entity -- A leaf node in a certification hierarchy: any entity in a @ref PKI which has a @ref certificate, but is |
|
200 not allowed to issue its own certificates.</td></tr> |
|
201 |
|
202 |
|
203 |
|
204 </table>\n @anchor F \n<table> |
|
205 |
|
206 <tr><td><b>F</b></td><td></td></tr> |
|
207 |
|
208 |
|
209 |
|
210 </table>\n @anchor G \n<table> |
|
211 |
|
212 <tr><td><b>G</b></td><td></td></tr> |
|
213 |
|
214 |
|
215 |
|
216 </table>\n @anchor H \n<table> |
|
217 |
|
218 <tr><td><b>H</b></td><td></td></tr> |
|
219 |
|
220 <tr><td>@anchor hash Hash</td> |
|
221 <td>Hash algorithms take a variable-length input and produce a fixed length output known as a digest, or hash, of the |
|
222 input. For cryptographic purposes they need to be one-way functions: it should not be possible to deduce the input |
|
223 from the digest, or even any part of the input. Also, it should be hard to find collisions: that is, two different |
|
224 inputs that produce the same output. See: |
|
225 @li @ref cryptographic_hash |
|
226 @li @ref SS_Cryptalg_hash_algorithms.</td></tr> |
|
227 |
|
228 <tr><td>@anchor HMAC HMAC</td> |
|
229 <td>Keyed-Hashing for Message Authentication -- A mechanism for message @ref authentication using cryptographic hashes. It |
|
230 can be used with any iterative cryptographic @ref hash function, e.g., @ref MD5, @ref SHA "SHA-1", in combination with a secret |
|
231 shared key. The cryptographic strength of HMAC depends on the properties of the underlying @ref hash function.</td></tr> |
|
232 |
|
233 |
|
234 |
|
235 </table>\n @anchor I \n<table> |
|
236 |
|
237 <tr><td><b>I</b></td><td></td></tr> |
|
238 |
|
239 <tr><td>@anchor ICC ICC</td> |
|
240 <td>Integrated Circuit Card -- A removable card with at least data storage and sometimes processing.</td></tr> |
|
241 |
|
242 <tr><td>@anchor IPSec IPSec</td> |
|
243 <td>IP Security Protocol -- A standard providing @ref secrecy and @ref authentication at the network or |
|
244 datagram layer of network communication. IPSec is mandatory in IPv6. \n |
|
245 See: <A HREF="http://www.ietf.org/html.charters/ipsec-charter.html">IPSec Working Group</A>.</td></tr> |
|
246 |
|
247 |
|
248 |
|
249 </table>\n @anchor J \n<table> |
|
250 |
|
251 <tr><td><b>J</b></td><td></td></tr> |
|
252 |
|
253 |
|
254 |
|
255 </table>\n @anchor K \n<table> |
|
256 |
|
257 <tr><td><b>K</b></td><td></td></tr> |
|
258 |
|
259 |
|
260 |
|
261 </table>\n @anchor L \n<table> |
|
262 |
|
263 <tr><td><b>L</b></td><td></td></tr> |
|
264 |
|
265 |
|
266 |
|
267 </table>\n @anchor M \n<table> |
|
268 |
|
269 <tr><td><b>M</b></td><td></td></tr> |
|
270 |
|
271 <tr><td>@anchor MD2 MD2</td> |
|
272 <td>Legacy @ref hash algorithm. Considered insecure.</td></tr> |
|
273 |
|
274 <tr><td>@anchor MD5 MD5</td> |
|
275 <td>Legacy @ref hash algorithm. Considered vulnerable.</td></tr> |
|
276 |
|
277 <tr><td>@anchor message_digest_algorithm Message Digest Algorithm</td> |
|
278 <td>Same as a @ref hash algorithm. </td></tr> |
|
279 |
|
280 <tr><td>@anchor MIDP MIDP</td> |
|
281 <td><A HREF="http://www.jcp.org/en/jsr/detail?id=118">Mobile Information Device Profile (JSP-118)</A>. |
|
282 -- A set of Java APIs that is generally implemented on the @ref CLDC "Connected Limited Device Configuration" (CLDC). |
|
283 It provides a basic J2ME application runtime environment targeted at mobile information devices, such as |
|
284 mobile phones and two-way pagers. The MIDP specification addresses issues such as user interface, persistent storage, |
|
285 networking, and application model.</td></tr> |
|
286 |
|
287 |
|
288 |
|
289 </table>\n @anchor N \n<table> |
|
290 |
|
291 <tr><td><b>N</b></td><td></td></tr> |
|
292 |
|
293 <tr><td>@anchor nonrepudiation Non-repudiation</td> |
|
294 <td>The process by which it is assured that an entity making a declaration cannot subsequently deny having made it: |
|
295 so I can't claim that I never wrote that cheque. </td></tr> |
|
296 |
|
297 |
|
298 |
|
299 </table>\n @anchor O \n<table> |
|
300 |
|
301 <tr><td><b>O</b></td><td></td></tr> |
|
302 |
|
303 <tr><td>@anchor OAEP OAEP</td> |
|
304 <td>Optimal Asymmetric Encryption Padding -- OAEP is a method for encoding messages, and addresses a potential |
|
305 vulnerability in <A HREF="http://www.rsasecurity.com/rsalabs/pkcs/pkcs-1/index.html">PKCS#1</A>. Padding means extra |
|
306 bits concatenated with a key, password, or @ref plaintext. @ref Padding helps against dictionary attacks.</td></tr> |
|
307 |
|
308 <tr><td>@anchor OCSP OCSP</td> |
|
309 <td>@ref X509 "X.509" Internet Public Key Infrastructure Online Certificate Status Protocol -- A simple request/response |
|
310 protocol. To establish whether a given @ref certificate or list of certificates has/have been revoked, a client forms an |
|
311 OCSP request and sends this to an OCSP server. The server maintains revocation information in the form of, say, |
|
312 Certificate Revocation Lists (@ref CRL "CRL"s). The server replies to the client with a signed OCSP response, stating for |
|
313 each certificate whether the status is Good, Revoked, or Unknown. This response in turn is checked to ensure that it |
|
314 is valid, and that it is from an entity trusted for performing revocation checking. |
|
315 See: |
|
316 @li <A HREF="http://www.ietf.org/rfc/rfc2560.txt">RFC2560</A> |
|
317 -- @ref X509 "X.509" Internet @ref PKI Online Certificate Status Protocol - OCSP |
|
318 @li @ref overview_OCSP overview. </td></tr> |
|
319 |
|
320 <tr><td>@anchor OID OID</td> |
|
321 <td>Object Identifier -- A universal constant uniquely associated with an object type used in @ref ASN "ASN.1".</td></tr> |
|
322 |
|
323 <tr><td>@anchor OS OS Element</td> |
|
324 <td>A discrete, identifiable entity within a ROM file that implements a set of interfaces. Examples of |
|
325 OS Elements include independently instantiable classes within DLLs, bitmaps within an MBM file, resource |
|
326 entries within a resource file. An OS Element identifies a part of a ROM file that could in principle be |
|
327 factored out or removed if it becomes architecturally advisable.</td></tr> |
|
328 |
|
329 <tr><td>@anchor out_of_band Out Of Band</td> |
|
330 <td>A channel of communication that is distinct from the channel which we are using cryptography to try to secure, |
|
331 and which is secure on its own terms; that is, its security is not dependent on the cryptography we are using. |
|
332 A common example of an out of band channel is a motorcycle courier. |
|
333 </td></tr> |
|
334 |
|
335 |
|
336 </table>\n @anchor P \n<table> |
|
337 |
|
338 <tr><td><b>P</b></td><td></td></tr> |
|
339 |
|
340 <tr><td>@anchor Padding @anchor padding Padding</td> |
|
341 <td>Extending the size of a block of @ref plaintext to, say, a 64-bit block by addition of a regular or random pattern. |
|
342 For example, for use with @ref ECB. See: |
|
343 @li @ref rsa_padding |
|
344 @li @ref symmetric_ciphers.</td></tr> |
|
345 |
|
346 <tr><td>@anchor PKCS PKCS</td> |
|
347 <td><A HREF="http://www.rsasecurity.com/rsalabs/pkcs/index.html">Public-Key Cryptography Standards</A>.</td></tr> |
|
348 |
|
349 <tr><td><A HREF="http://www.rsasecurity.com/rsalabs/pkcs/pkcs-10/index.html">PKCS#10</A></td> |
|
350 <td>@ref PKI standard that describes how to construct @ref certificate requests.</td></tr> |
|
351 |
|
352 <tr><td>@anchor PKG PKG file</td> |
|
353 <td>A text file that defines a @ref SIS file. The PKG file is passed to the MAKESIS tool to produce the |
|
354 @ref SIS file.</td></tr> |
|
355 |
|
356 <tr><td>@anchor PKI PKI</td> |
|
357 <td>Public Key Infrastructure -- A way of modelling real-world trust relationships that enables users of |
|
358 @ref public_key_cryptography "public key cryptography" to have confidence in the ownership of the @ref public_key "public keys" they are using. A PKI consists of: |
|
359 @li a trusted third party (@ref TTP) |
|
360 @li an @ref out_of_band "out of band" means of distributing the @ref TTP's @ref public_key_certificate "public key certificate" to @ref relying_party "relying parties" |
|
361 @li a means of distributing other certificates to @ref relying_party "relying parties" |
|
362 @li arrangements for the @ref revocation and renewal of these certificates |
|
363 @li certificate management and validation software on the @ref relying_party "relying party's" computer |
|
364 |
|
365 The TTP uses its signing key pair to create certificates for other entities, which relying parties can use to |
|
366 authenticate these other entities. |
|
367 |
|
368 We can classify PKIs according to whether they are hierachical or flat. In hierachical PKIs, such as the one defined |
|
369 in the PKIX set of standards, there is a distinction between users of the PKI such as End Entities (@ref EE "EE"s) and |
|
370 @ref relying_party "relying parties", and entities responsible for issuing and distributing certificates such as @ref CA "CA"s and |
|
371 @ref RA "RA"s. In a flat PKI such as the @ref web_of_trust "web of trust" underpinning @ref PGP, there are no entities whose sole role is |
|
372 to issue certificates; instead users of the PKI certify each other. </td></tr> |
|
373 |
|
374 <tr><td>@anchor PKIX PKIX</td> |
|
375 <td>Public-Key Infrastructure (X.509) -- A profile of @ref X509 "X.509" for the internet. See: |
|
376 @li @ref Certman_X509_Certificate_Validation |
|
377 @li <A HREF="http://www.ietf.org/rfc/rfc2459.txt">RFC2459</A> |
|
378 -- Internet X.509 Public Key Infrastructure Certificate and CRL Profile.)</td></tr> |
|
379 |
|
380 <tr><td>@anchor plaintext Plaintext</td> |
|
381 <td>The output of an @ref decryption operation, or the input to a @ref encryption operation.</td></tr> |
|
382 |
|
383 <tr><td>@anchor PGP PGP</td> |
|
384 <td>Pretty Good Privacy -- A very widely-used @ref encryption and digital signing program.</td></tr> |
|
385 |
|
386 <tr><td>@anchor private_key Private Key</td> |
|
387 <td>In the context of @ref public_key_cryptography "public key cryptography", the private half of the key pair.</td></tr> |
|
388 |
|
389 <tr><td>@anchor public_key Public Key</td> |
|
390 <td>In the context of @ref public_key_cryptography "public key cryptography", the public half of the key pair.</td></tr> |
|
391 |
|
392 <tr><td>@anchor public_key_certificate Public Key Certificate</td> |
|
393 <td>A digitally signed structure including at least an identifier for an individual entity and a @ref public_key "public key", whose |
|
394 function is to bind the entity with the key. </td></tr> |
|
395 |
|
396 <tr><td>@anchor public_key_cryptography Public Key Cryptography</td> |
|
397 <td>A common application of @ref asymmetric cryptography in which one half of the key pair is kept secrect |
|
398 (the @ref private_key "private key") and the other half is published (the @ref public_key "public key"). See: |
|
399 @li @ref asymmetric_cryptography |
|
400 @li @ref Security_intro_PKC.</td></tr> |
|
401 |
|
402 |
|
403 |
|
404 </table>\n @anchor Q \n<table> |
|
405 |
|
406 <tr><td><b>Q</b></td><td></td></tr> |
|
407 |
|
408 |
|
409 |
|
410 </table>\n @anchor R \n<table> |
|
411 |
|
412 <tr><td><b>R</b></td><td></td></tr> |
|
413 |
|
414 <tr><td>@anchor RA Registration Authority</td> |
|
415 <td>An organization responsible for registering new @ref certificate users in a @ref PKI, e.g. by gathering and verifying |
|
416 information which identifies the @ref certificate applicant.</td></tr> |
|
417 |
|
418 <tr><td>@anchor revocation Revocation</td> |
|
419 <td>The term used for asserting that a @ref certificate is no longer valid: for example, because the @ref private_key "private key" |
|
420 associated with it has been compromised.</td></tr> |
|
421 |
|
422 <tr><td>@anchor relying_party Relying Party</td> |
|
423 <td>An entity who relies on the authenticity of a @ref public_key "public key".</td></tr> |
|
424 |
|
425 <tr><td>@anchor root_certificate Root Certificate</td> |
|
426 <td>The @ref certificate of a @ref TTP "trusted third party". A certificate directly trusted by a @ref relying_party "relying party" |
|
427 that is, trust in it is not established by cryptographic means, but trust in it is the prerequisite for establishing |
|
428 trust in the entity which the relying party is trying to authenticate. Trust in a root certificate must be established |
|
429 through @ref out_of_band "out of band" means. A root certificate may or may not be self signed.\n\n |
|
430 See: @ref certman_certstore_root_cert_management.</td></tr> |
|
431 |
|
432 <tr><td>@anchor RSA <A HREF="http://www.rsasecurity.com/rsalabs/rsa_algorithm/index.html">RSA</A></td> |
|
433 <td>A @ref public_key "public key" algorithm used for both @ref encryption and @ref digital_signature "digital signatures", named after its creators: |
|
434 Rivest, Shamir, and Adleman.</td></tr> |
|
435 |
|
436 |
|
437 </table>\n @anchor S \n<table> |
|
438 |
|
439 <tr><td><b>S</b></td><td></td></tr> |
|
440 |
|
441 <tr><td>@anchor secrecy Secrecy</td> |
|
442 <td>This means that access to information is controlled: for example, it means that two entities (e.g. people, |
|
443 machines, processes) are able to communicate with one another without any other entities being able to access the |
|
444 information communicated, or that an entity may store some information and be assured that only this entity will be |
|
445 able to access it.</td></tr> |
|
446 |
|
447 <tr><td>@anchor SHA SHA-1</td> |
|
448 <td>Secure Hash Algorithm 1 -- A widely used @ref hash algorithm, producing a 160-bit digest. </td></tr> |
|
449 |
|
450 <tr><td>@anchor server_authentication Server Authentication</td> |
|
451 <td>In a secure client-server protocol such as @ref TLS, the process in which the server authenticates itself to the |
|
452 client, so the client knows to whom it's talking. \n See: @ref WTLS_server_authentication "Server authentication in WTLS".</td></tr> |
|
453 |
|
454 <tr><td>@anchor SignText SignText</td> |
|
455 <td>A function defined in the @ref WMLScript Crypto API that provides application-level @ref authentication and |
|
456 @ref nonrepudiation "non-repudiation" for transactions. </td></tr> |
|
457 |
|
458 |
|
459 <tr><td>@anchor SIS SIS file</td> |
|
460 <td>A binary package file containing all the files for an installation, as well as metadata describing which |
|
461 directory to install them into, dependencies, etc..\n |
|
462 See: @ref overview_SWI overview.</td></tr> |
|
463 |
|
464 <tr><td>@anchor Stub SIS Stub file</td> |
|
465 <td>A @ref SIS file containing only the metadata, and not the files. After the installation, this file is archived |
|
466 on the device for uninstallation purposes, etc..</td></tr> |
|
467 |
|
468 <tr><td>@anchor SMIME S/MIME</td> |
|
469 <td><A HREF="http://www.ietf.org/html.charters/smime-charter.html">Secure/Multipurpose Internet Mail Extensions</A> |
|
470 -- Provides a consistent way to send and receive secure MIME data. S/MIME provides the following cryptographic |
|
471 security services for electronic messaging applications: @ref authentication, message integrity and @ref nonrepudiation "non-repudiation" of |
|
472 origin (using @ref digital_signature "digital signatures") and privacy and data security (using @ref encryption); see |
|
473 <A HREF="http://www.ietf.org/rfc/rfc2633.txt">RFC2633</A> -- S/MIME Version 3 Message Specification. |
|
474 </td></tr> |
|
475 |
|
476 <tr><td>@anchor SSL SSL</td> |
|
477 <td>Secure Sockets Layer -- A protocol for securing network connections that provides @ref authentication, @ref encryption, and |
|
478 data integrity using @ref PKI "Public Key Infrastructure" (PKI). Precursor to @ref TLS. SSL has been through three versions: |
|
479 the first two are considered insecure, and the third is almost identical to @ref TLS.</td></tr> |
|
480 |
|
481 <tr><td>@anchor stream_cipher Stream Cipher</td> |
|
482 <td>A class of symmetric algorithm that is initialised with a key, then outputs a stream of pseudorandom bits. |
|
483 This 'keystream' is typically XOR-ed with the @ref plaintext to generate the @ref ciphertext. So they encrypt a bit of |
|
484 plaintext at a time. </td></tr> |
|
485 |
|
486 <tr><td>@anchor symmetric_cryptography Symmetric Cryptography</td> |
|
487 <td>A form of cryptography in which the same key is used for @ref encryption and @ref decryption.\n\n |
|
488 Symmetric cryptography is fast, but suffers from the problem of how to distribute the key privately. @ref Asymmetric |
|
489 cryptography is an attempt to alleviate the key distribution problem, by reducing the requirement for the distributed |
|
490 key from one of privacy to one of @ref authentication. See: |
|
491 @li @ref symmetric_ciphers |
|
492 @li @ref SS_Cryptalg_symmetric_ciphers.</td></tr> |
|
493 |
|
494 |
|
495 </table>\n @anchor T \n<table> |
|
496 |
|
497 <tr><td><b>T</b></td><td></td></tr> |
|
498 |
|
499 <tr><td>@anchor TLS TLS</td> |
|
500 <td>Transport Layer Security -- A protocol that provides communications secrecy, and optionally @ref authentication, |
|
501 over the Internet TCP/IP. The protocol allows client/server applications to communicate in a way that is designed to |
|
502 prevent eavesdropping, tampering, or message forgery. |
|
503 |
|
504 In this protocol a client connects to a server; the two then perform a handshake in which they exchange a |
|
505 symmetric key by using @ref asymmetric cryptography, which is then used to encrypt their communications, |
|
506 providing the @ref secrecy element. Without the @ref authentication element, @ref secrecy is not very useful; although |
|
507 only client and server can understand the data exchanged, the client doesn't know who the server is or vice versa. TLS |
|
508 provides the capability for @ref WTLS_server_authentication "server authentication", in which the client establishes who the server is, and |
|
509 @ref client_authentication "client authentication" in which the server establishes who the client is. \n\n |
|
510 See: <A HREF="http://www.ietf.org/rfc/rfc2246.txt">RFC2246</A> -- |
|
511 The TLS Protocol). TLS is the successor to the @ref SSL "Secure Sockets Layer" (SSL). (Also, see: @ref WTLS.)</td></tr> |
|
512 |
|
513 <tr><td>@anchor TTP TTP</td> |
|
514 <td>Trusted Third Party -- An entity whose @ref public_key "public key" is known to a @ref relying_party "relying party" due to its having been received |
|
515 via @ref out_of_band "out of band" means, and which is trusted to issue @ref public_key_certificate "public key certificates" for other entities not directly |
|
516 known to the relying party. A @ref CA is a type of TTP. </td></tr> |
|
517 |
|
518 |
|
519 </table>\n @anchor U \n<table> |
|
520 |
|
521 <tr><td><b>U</b></td><td></td></tr> |
|
522 |
|
523 <tr><td>@anchor URI URI</td> |
|
524 <td>Uniform Resource Identifier -- A way to identify some content on the Internet, typically through the use of an |
|
525 identifier for the scheme (e.g. HTTP) through which the content may be accessed, and an identifier for the |
|
526 content that makes sense within that scheme. |
|
527 The most common form of URI is a Web page address, which is a particular form or subset of URI called a Uniform |
|
528 Resource Locator (URL).</td></tr> |
|
529 |
|
530 |
|
531 |
|
532 </table>\n @anchor V \n<table> |
|
533 |
|
534 <tr><td><b>V</b></td><td></td></tr> |
|
535 |
|
536 |
|
537 |
|
538 </table>\n @anchor W \n<table> |
|
539 |
|
540 <tr><td><b>W</b></td><td></td></tr> |
|
541 |
|
542 <tr><td>@anchor WAP WAP</td> |
|
543 <td></td><A HREF="http://www.wapforum.org/index.htm">Wireless Application Protocol</A> -- A secure specification |
|
544 that enables users to access information instantly using devices such as mobile phones, pagers, two-way radios, |
|
545 smartphones and communicators. The WAP defines a set of protocols in transport, security, transaction, session, and |
|
546 application layers to enable the creation of advanced mobile services.</td></tr> |
|
547 |
|
548 <tr><td>@anchor web_of_trust Web of Trust</td> |
|
549 <td>The set of social relationships between users of @ref PGP that enables them to sign each others' keys, essentially |
|
550 providing a @ref PKI for this technology.</td></tr> |
|
551 |
|
552 <tr><td>@anchor WIM WIM</td> |
|
553 <td><A HREF="http://www.wmlclub.com/docs/especwap2.0/WAP-260-WIM-20010712-a.pdf">Wireless Identity Module</A> |
|
554 -- Used in performing @ref WTLS and application level security functions, and especially, to store and process |
|
555 information needed for user identification and @ref authentication. Examples of WIM implementations are a Subscriber |
|
556 Identity Module (SIM) card or an external smart card.</td></tr> |
|
557 |
|
558 <tr><td>@anchor WMLScript WMLScript Crypto API</td> |
|
559 <td>A @ref WAP Forum standard that defines cryptographic functions in WML, the scripting language used in @ref WAP. |
|
560 It defines a function for creating signed objects called @ref SignText.</td></tr> |
|
561 |
|
562 <tr><td>@anchor WTLS WTLS</td> |
|
563 <td><A HREF="http://www.wmlclub.com/docs/especwap2.0/WAP-261-WTLS-20010406-a.pdf">Wireless Transport Layer Security</A> |
|
564 -- The security layer of the @ref WAP, providing privacy, data integrity and @ref authentication for WAP services. |
|
565 It is a @ref WAP variant of @ref TLS and defines its own lightweight @ref certificate format. \n\n |
|
566 See: @ref overview_WTLS overview. </td></tr> |
|
567 |
|
568 <tr><td>@anchor WTLS_certificate WTLS certificate</td> |
|
569 <td>@ref WAP variant of @ref X509_certificate "X.509 certificates".\n\n |
|
570 See: @ref overview_WTLS overview.</td></tr> |
|
571 |
|
572 |
|
573 </table>\n @anchor X \n<table> |
|
574 |
|
575 <tr><td><b>X</b></td><td></td></tr> |
|
576 |
|
577 <tr><td>@anchor X509 X.509</td> |
|
578 <td>A widely used standard for digital certificates. See: |
|
579 @li @ref Certman_X509_Certificate_Validation |
|
580 @li <A HREF="http://www.ietf.org/rfc/rfc2459.txt">RFC2459</A> |
|
581 -- Internet @ref X509 "X.509" @ref PKI Certificate and @ref CRL Profile |
|
582 @li <A HREF="http://www.ietf.org/rfc/rfc3280.txt">RFC3280</A> |
|
583 -- Internet @ref X509 "X.509" @ref PKI Certificate and @ref CRL "Certificate Revocation List" Profile. |
|
584 </td></tr> |
|
585 |
|
586 <tr><td>@anchor X509_certificate X.509 certificate</td> |
|
587 <td>A widely used type of @ref public_key_certificate "public key certificate", part of the now largely moribund X.500 series of standards.\n\n |
|
588 An X.509 certificate is a person's/company's @ref public_key "public key" digitally signed by a trusted third party and wrapped with |
|
589 attribute data such as identifying names. A hierarchy of certificates is often used tracing back to a single root |
|
590 @ref CA_certificate "CA certificate". If a user trusts the @ref CA, then they can trust that the @ref certificate belongs to the |
|
591 person/company given within the certificate. Using the public key within the certificate, they can then verify that |
|
592 other data has originated from the certificate owner via the use of @ref digital_signature "digital signatures" created using the corresponding |
|
593 @ref private_key "private key". @ref X509 "X.509" basically defines the certificate format.</td></tr> |
|
594 |
|
595 |
|
596 |
|
597 </table>\n @anchor Y \n<table> |
|
598 |
|
599 <tr><td><b>Y</b></td><td></td></tr> |
|
600 |
|
601 |
|
602 </table>\n @anchor Z \n<table> |
|
603 |
|
604 <tr><td><b>Z</b></td><td></td></tr> |
|
605 |
|
606 <tr><td>@anchor zlib zlib</td> |
|
607 <td>zlib is designed to be a free, general-purpose, legally unencumbered (i.e., not covered by any patents) lossless |
|
608 data-compression library for use on virtually any computer hardware and operating system. zlib was written by |
|
609 Jean-loup Gailly (compression) and Mark Adler (decompression). See: |
|
610 @li <A HREF="http://www.ietf.org/rfc/rfc1950.txt">RFC1950, zlib format</A> |
|
611 @li <A HREF="http://www.ietf.org/rfc/rfc1951.txt">RFC1951, deflate format</A> |
|
612 @li <A HREF="http://www.ietf.org/rfc/rfc1952.txt">RFC1952, gzip</A>.</td></tr> |
|
613 |
|
614 </table> |
|
615 */ |
|