# HG changeset patch
# User Dremov Kirill (Nokia-D-MSW/Tampere) \\\\Londata04\\Psisoft\\Dev\\GT\\0128 Hurricane WAP
unless otherwise stated.
-
--# Hurricane Security Framework Functional Specification, "HSF FS.doc"
--# Certificate Management(Hurricane) Functional Specification
-
-@section cryptotokens_tsecdlg The dummy security dialog notifier
-
-See @ref cryptotokens_TSecdlg
-
-@section cryptotokens_revs Revision History
-
-
-
-
-
- */
-/**
- @page cryptotokens_Writing Writing a token type
-
- A token type is an ECom plugin that represents a particular
- implementation of cryptographic functions, for instance a WIM or a
- particular file-based certificate store.
-
- The process of writing one can be divided into the following steps:
-
- @ref cryptotokens_UIDs
-
- @ref cryptotokens_Framework
-
- @ref cryptotokens_Resource
-
- @ref cryptotokens_TokenType
-
- @ref cryptotokens_TokenInfo
-
- @ref cryptotokens_Token
-
- @ref cryptotokens_Interfaces
-
- */
-/**
- @page cryptotokens_UIDs Understanding the use of UIDs in the framework
-
- Lots of different things are associated with UIDs. It's important
- to understand what they all are.
-
- The Token Type base class is an Interface as far as ECom is
- concerned, and has a UID to identify it. This UID is defined by the
- framework, and there's a define for it, CT_INTERFACE_UID. All you
- need to do with this UID is put it in the right place in the
- resource file.
-
- Each DLL has a UID, just like normal. Your DLL will need one. ECom
- requires your resource file to be named after the UID of the DLL.
-
- Each Token Type has a UID. It is possible (but unusual) to have several token
- types in 1 DLL, which is why they each need a UID to identify them.
-
- Each interface and attribute also has a UID to identify
- them. Normaly the interfaces and attributes will have been defined
- as part of the framework, so there will be defines for these
- values.
-
- Next: @ref cryptotokens_Framework
- Previous: @ref cryptotokens_Writing
-
- */
-/**
- @page cryptotokens_Resource Writing the resource file.
-
- The resouce file generaly follows the ordinary format of an ECom
- resource file. It must be named after the UID of the
- implementation. The match data is interpreted as a list of UIDs of
- supported interfaces. The Opaque data contains the attributes,
- which are represented as pairs of UIDs and 4 byte values.
-
- Due to limitations in the format of ECom resource files, these
- resources must be specified as a list of bytes, with the LSB being
- first in each word of 4 bytes. An example is probably needed:
- @code
-// 101F4E4e.RSS
-//
-
-// This header file contains all the defines you need.
-#include "ct/CryptoTokenRegistryInfo.rh"
-RESOURCE REGISTRY_INFO theInfo
- {
- // This is the UID of the DLL, and also the name of this file.
- dll_uid = 0x101F4E4e;
- interfaces =
- {
- INTERFACE_INFO
- {
- // This is the ECom interface ID of all CT Token types
- interface_uid = CT_INTERFACE_UID;
- implementations =
- {
- BINARY_IMPLEMENTATION_INFO
- {
- implementation_uid = 0x101f4e4c; // UID of the token type
- version_no = 1; // Version number of this token type
- display_name = "Test Token Type 6"; // Human-readable name
- // Supported interfaces:
- default_data = {0x50, 0x4e, 0x1f, 0x10, // UID 0x101f4e50
- 0x51, 0x4e, 0x1f, 0x10, // UID 0x101f4e51
- 0x52, 0x4e, 0x1f, 0x10};// UID 0x101f4e52
- opaque_data = { 0x4b, 0x4e, 0x1f, 0x10, // attr 2 UID 0x101f4e4b
- 0x02, 0x00, 0x00, 0x00, // attr 2 value (2)
- 0x4a, 0x4e, 0x1f, 0x10, // attr 1 UID 0x101f4e4a
- 0x01, 0x00, 0x00, 0x00};// attr 1 value (1)
- }
-
- };
- }
- };
- }
-
- @endcode
-
- Next: @ref cryptotokens_TokenType
- Previous: @ref cryptotokens_Resource
-
-
- */
-/**
- @page cryptotokens_Framework Writing the framework of the DLL and static classes.
-
- The DLL must be built with the target type ECOMIIC. This is an
- example of a simple mmp file for a token type DLL:
- @code
-TARGET TestPlugin.dll
-TARGETTYPE ECOMIIC
-
-// ECom Dll recognition UID followed by the unique UID for this dll
-UID 0x10009D8D 0x101F4E4E
-
-SOURCEPATH .
-SOURCE TestPlugin.cpp
-
-SYSTEMINCLUDE \epoc32\include \epoc32\include\ecom
-
-RESOURCE 101F4E4E.rss
-
-LIBRARY euser.lib
-LIBRARY ctframework.lib
- @endcode
-
- The DLL will need an E32Dll function, like any other SymbianOS
- DLL. For instance, in most cases it can look like this:
- @code
-GLDEF_C TInt E32Dll(TDllReason)
- {
- return ETrue;
- }
- @endcode
-
- Then a standard ECom ImplementationTable and
- ImplementationGroupProxy function is needed. Assuming your plugin
- has 1 token type in, it'll look something like this:
- @code
-// An array listing the NewL functions of all the plugins. In this
-// case, there is only 1. The UID of the token type is 0x101F4E4D.
-const TImplementationProxy ImplementationTable[] =
- {
- {{0x101F4E4D}, CTokenTypeImplementation::NewL},
- };
-
-// This function is needed by ECom. It will probably always look like this.
-EXPORT_C const TImplementationProxy* ImplementationGroupProxy(TInt& aTableCount)
- {
- aTableCount = sizeof(ImplementationTable) / sizeof(TImplementationProxy);
-
- return ImplementationTable;
- }
- @endcode
-
- Next: @ref cryptotokens_Resource
- Previous: @ref cryptotokens_UIDs
-
- */
-/**
- @page cryptotokens_TokenType Writing the Token Type class
-
- The token type class needs to implement the CTokenType
- interface. This means it needs to return a list of CTokenInfo
- objects representing every token available, and to open a token
- based on a CTokenInfo object.
-
- Both the listing of the token infos and opening tokens are
- asynchronous as they may need to talk to slow external tokens such
- as WIMs.
-
- Next: @ref cryptotokens_TokenInfo
- Previous: @ref cryptotokens_Resource
-
-
- */
-/**
- @page cryptotokens_TokenInfo Writing the Token Info class
-
- By default, the CTokenInfo contains just a label, which allows the
- user to identify which token they want to use. You can add other
- data to allow you to identify which token it refers to. If your
- token type only supports 1 token, this class will be very trivial.
-
- Next: @ref cryptotokens_Token
- Previous: @ref cryptotokens_TokenType
-
- */
-/**
- @page cryptotokens_Token Writing the Token class
-
- The token is a subclass of MCTToken. You must define the functions
- to create interfaces, and the release function. The client must
- call Release once when it has finished with the token. In addition,
- you may wish to implement a reference counting mechanism so that
- the token object is held open until the Release functions in the
- interfaces are called.
-
- The token will almost certainly need a pointer to the token type,
- and the interfaces to the token.
-
- Next: @ref cryptotokens_Interfaces
- Previous: @ref cryptotokens_TokenInfo
-
- */
-/**
- @page cryptotokens_Interfaces Implementing the interfaces
-
- You now need to implement the interfaces that your token
- supports. How to do this is described in the documentation for each
- interface.
-
- Contents: @ref cryptotokens_Writing
-
-*/
-/** @page cryptotokens_refcount The Use of Reference Counting in the framework
-The token type counts active references to it. When it is created its reference count is set to 1. Each time it constructs and returns a token it increments its reference count. Its Release decrements the reference count: if the result is zero the token type resources are freed.
-
-The token counts active references to it. When it is created its reference count is set to 1. Each time it constructs and returns an interface it increments its reference count. Its Release() decrements the reference count: if the result is zero the token's own resources are freed, and the token calls TokenType().Release(), to signal that it no longer needs the token.
-
-The token interface base class implements its Release() function by calling its DoRelease() function to free its own resources, then calling Token().Release() to signal to the token that it no longer needs it.
-
-This enables application code to create a token type, use it to create a token, then release the token type, then use the token to create an interface, then release the token; it can then, for example, pass the interface to another object without needing to worry about the fate of the token type, or the token.
-
-The sequence diagram below shows the operation of the reference counting.
-
-- the application creates a token type, whose reference count is set to 1 (1&2)
-- the application uses the token type to create two tokens A and B: each token is created with a reference count of one, and the token type's reference count is incremented each time (7&11) so is now 3
-- the application releases the token type, so its reference count is decremented (11 & 12)
-- the application opens two interfaces implemented on token A (interfaces 1 & 2); each time the token's reference count is incremented, so is now 3 (14-17)
-- the application releases token A, so its reference count is decremented to 2 (18-19)
-- this process is repeated for token B (20-28): now we have 1 token type which has generated 2 tokens, each of which has generated 2 interfaces, which hold the only handles to the interfaces. The application can now forget about the ownership of the token types and tokens.
-- when the application has finished with the interfaces it releases them. When each interface is released it releases the token hosting it, which decrements the reference count. When all the interfaces hosted by a token have released the token the reference count is zero and the token cleans up its own resources and releases the token type When both tokens have released the token type its own reference count is zero, so it frees its own resources.
-@image html sequence.bmp "Reference Counting Sequence Diagram"
-*/
diff -r c11c717470d0 -r 11c66574c2a2 cryptomgmtlibs/cryptotokenfw/docsrc/sequence.bmp
Binary file cryptomgmtlibs/cryptotokenfw/docsrc/sequence.bmp has changed
diff -r c11c717470d0 -r 11c66574c2a2 cryptomgmtlibs/cryptotokenfw/docsrc/tsecdlg.dox
--- a/cryptomgmtlibs/cryptotokenfw/docsrc/tsecdlg.dox Fri Apr 16 16:52:34 2010 +0300
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,190 +0,0 @@
-/**
-
-@page cryptotokens_TSecdlg tsecdlg - The dummy security dialog notifier
-
-@section tsecdlg_intro Introduction
-
-This document describes tsecdlg, the dummy security dialog notifier.
-
-The security dialog API provides a way for components to ask the user various
-standard security-related questions. For example, it contains methods to prompt
-the user to enter a passphrase, among others. The API is defined in the file
-secdlg.h.
-
-It is necessary to write test harnesses for clients of this API which can be run
-unattended, without user intervention. To achieve this, tsecdlg was developed.
-It allows user responses to security dialogs to be pre-defined, and enables a
-test harness to check that the expected dialogs would have been displayed to the
-user.
-
-@section tsecdlg_secdlg_implementation Security dialog implementation
-
-The dialogs that the user sees cannot be implemented as part of the security
-subsystem because they form part of the user interface layer. So the security
-dialog API passes client requests to the security dialog notifier. This is a
-type of plugin, and is typically supplied by the UI implementation - for example
-by techview. The protocol used to pass messages to and from the plugin is
-defined in the file secDlgImplDefs.h.
-
-tsecdlg is just an implementation of the security dialog notifier that doesn't
-ask the user for information. Instead it either gives default responses or
-reads them from a file.
-
-@section tsecdlg_when_to_use_tsecdlg When it's necessary to use tsecdlg
-
-Any test that directly or indirectly uses the security dialog API will require
-the use of tsecdlg if the tests are to be run unattended. At the moment, the
-keystore is the main client of this API. The keystore tests rely heavily on
-tsecdlg, and anything that uses keystore will probably need to use it as well -
-for example TLS.
-
-
-Date Version Status Description
-25-10-2001 0.01 DRAFTversion First draftversion
-31-10-2001 0.02 DRAFTversion Updated after review
-15-11-2001 0.03 DRAFTversion Updated following small changes after actual implementation
-23-11-2001 0.04 DRAFTversion Changes to Security Dialog API - dropped Sign in favour of EstablishSecureConnection
-21-12-2001 1.00 ISSUED Issued
-02-01-2002 1.01 PROPOSED Extended, converted to Doxygen format and updated to reflect current APIs
-18-03-2002 2.00 ISSUED Minor updates
-
-@section tsecdlg_preparation Preparation for running tests that use tsecdlg
-
-@section tsecdlg_building_tsecdlg Building tsecdlg
-
-Two versions of tsecdlg are built on all platforms - one for the extended
-notifier framework (ie graphical notifiers, or techview) and one for textshell.
-This means that tests will work in both environments.
-
-To build tsecdlg just requires building the test code supplied in the
-security cryptotokens component, eg:
-
-\code
-cd common\generic\security\cryptotokens\group
-bldmake bldfiles
-abld test build wins udeb
-\endcode
-
-There are two tsecdlg components:
-
-
-
-
-@section tsecdlg_emulator_testing Testing on the emulator
-
-If you are running in techview mode, you must ensure that the techview
-implementation of the security dialog notifier (secdlg.dll) is not present (if
-both secldg.dll and tsecdlg.dll are present, epoc will crash). This can be
-found in in z:\\system\\notifiers, for example
-\\epoc32\\release\\wins\\udeb\\z\\system\\notifiers for wins udeb. The easiest
-way to ensure secdlg.dll is removed is to use the following command:
-
-\code
-del /s /f /q \epoc32\secdlg.dll
-\endcode
-
-This does not matter for textshell mode, because there is no default textshell
-security dialog plugin.
-
-@section tsecdlg_hardware_testing Testing on hardware
-
-To test on hardware, the appropriate dll (either techview or textshell) must be
-included in the ROM in the same location as it is in the emulator (ie
-z:\\system\\notifiers for techview mode). This can be done adding the following
-line to an iby file:
-
-\code
-file=ABI_DIR\BUILD_DIR\tsecdlg.dll System\Notifiers\tsecdlg.dll
-\endcode
-
-This is done for security tests in the file filetokenstests.iby.
-
-Note that if you are using techview mode, you must ensure that secdlg.dll is not
-included - you must edit \\epoc32\\rom\\include\\secui.iby and comment out the
-following line:
-
-\code
-file=ABI_DIR\BUILD_DIR\secdlg.dll System\Notifiers\Secdlg.dll
-\endcode
-
-
-Name Location Description
-t_secdlg z:\\system\\notifiers\\tsecdlg.dll Extended notifier
-t_secdlg_text z:\\system\\tnotifiers\\tsecdlg_text.dll Textshell notifier
-
-@section tsecdlg_cryptotokens_operation tsecdlg operation
-
-tsecdlg has two modes of operation:
-
-@li Default mode
-@li Scripted mode
-
-@section tsecdlg_default_mode Default mode
-
-This is the simpler mode. Whenever the dialog for a passphrase is triggered,
-tsecdlg replies with a default passphrase ('pinkcloud').
-
-This is intended to used by test code that is not directly testing a client of
-the security dialog API, for example by TLS.
-
-tsecdlg runs in this mode when the files c:\\t_secdlg_in.dat and
-c:\\t_secdlg_out.dat are not present.
-
-@section tsecdlg_scripted_mode Scripted mode
-
-This mode is more complex, and is intended to be used by for testing direct
-clients of the security dialog API - for example the keystore.
-
-Before a test is run, a file of expected dialogs and the required responses is
-prepared. Every time the security dialog API is called and tsecdlg invoked, it
-checks that the requested dialog is the one expected, and answers with the
-pre-determined response. An unexpected dialog request produces an error. A
-file containing the number of correctly answered dialog requests is maintained
-and this allows the test harness to determine whether all expected dialogs were
-triggered correctly.
-
-The list of expected dialogs is read from c:\\t_secdlg_in.dat. This has the
-following format:
-
-
-
-
-Then, for every expected dialog, the following data is present. Strings are
-represented with their size (TInt32) followed by that many bytes of data.
-
-Type Description
-
-TInt32 Number of dialogs expected
-
-
-The expected operation should be a member of the TSecurityDialogOperation
-enumeration - this specifies the expected type of dialog that is requested (for
-example, the enter passphrase dialog). If the requested operation is not the
-same as this, the operation is completed with KErrOperationMismatch. If the
-operation is one that is not supported by tsecdlg (only the ones necessary for
-testing keystore are currently implemented), the operation is completed with
-KErrOperationNotSupported.
-
-The expected label allows the test code to specify the label passed to the API.
-It is matched if the actual label contains the expected label - this means that
-passing an empty string will always ensure a match. If the expected label is
-not matched, the operation is completed with KErrLabelMismatch.
-
-The responses are the information tsecdlg passes back as if from the user. Some
-operations (eg change PIN) return two pieces of information, but for the most
-part only the first one is used.
-
-The error codes are summarised below. Note that as this is test code, these are
-not officially allocated!
-
-
-Type Description
-TInt32 Expected operation
-String Expected label
-String Response 1
-String Response 2 (not always used)
-
-
-Every time a request is succesfully answered, the file c:\\t_secdlg_out.dat is
-updated - it contains a single TInt32 that indicates the index of the current
-dialog in the list of expected dialogs described by c:\\t_secdlg_in.dat. If it
-is not present, its value is assumed to be zero.
-
-*/
diff -r c11c717470d0 -r 11c66574c2a2 cryptomgmtlibs/cryptotokenfw/inc_interfaces/doxygen_docs/Crypto_Interfaces_index.dox
--- a/cryptomgmtlibs/cryptotokenfw/inc_interfaces/doxygen_docs/Crypto_Interfaces_index.dox Fri Apr 16 16:52:34 2010 +0300
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,11 +0,0 @@
-/**
-@page page_cryptoInterfaces Cryptographic interfaces
-
-Welcome to Cryptographic Interfaces
-
-@li Authentication object management interface
-@li Certificate storage interface
-@li Key storage interface
-
-
-*/
\ No newline at end of file
diff -r c11c717470d0 -r 11c66574c2a2 cryptomgmtlibs/cryptotokenfw/source/ctframework/doxygen_docs/Key_management_index.dox
--- a/cryptomgmtlibs/cryptotokenfw/source/ctframework/doxygen_docs/Key_management_index.dox Fri Apr 16 16:52:34 2010 +0300
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,5 +0,0 @@
-/**
-
-@page mainpage_key_management Key Management
-
-*/
\ No newline at end of file
diff -r c11c717470d0 -r 11c66574c2a2 cryptomgmtlibs/securitydocs/Security_Glossary.html
--- 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 @@
-
-
-
-Name Code Description
-KErrTooManyDialogs -12000 More dialogs have been requested than are described in the input file
-KErrLabelMismatch -12001 The label requested did not match the expected value
-KErrOperationMismatch -12002 The operation requested did not match the expected value
-KErrOperationNotSupported -12003 The operation requested is not implemented by tsecdlg
-
-
-
-
-
-
-
-
-
-Security Classification
-
-
-Internal
-
-
-
-
-
-Document Reference
-
-
-SGL.GT0128.56
-
-
-
-
-
-Status
-
-
-Draftversion
-
-
-
-
-
-Version
-
-
-0.1
-
-
-
-
-
-Team/Department
-
-
-Security Team
-
-
-
-
-
-Author
-
-
-William Bamberg
-
-
-
-
-
-Owner
-
-
-Security Team
-
-
- | |
-Asymmetric Cryptography - | -
-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.
- -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. - |
-
-Attribute Certificate - | --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. - | -
-Authentication - | --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. - | -
-Block Cipher - | --A class of symmetric algorithm 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. - | -
-CA Certificate - | --A certificate held by a CA: the key pair associated with it is used for -signing certificates issued by that CA. May or may not be self-signed. - | -
-Certificate - | --For our purposes, this is the same thing as a -public key certificate - | -
Certification Authority (CA) - | -
-An organization which perform the following functions in a hierachical PKI:
-
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 self-signed certificate to afford some degree of tamper evidency. - 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 cross certificates, which enable interoperation -between two distinct PKIs. - |
-
-Ciphertext - | --The output of an encryption operation, or -the input to a decryption operation. - | -
-Client Authentication - | --In a secure client-server protocol such as TLS, the process in which the client -authenticates itself to the server, so the server knows who it's talking to. - | -
-Client/User/End Entity Certificate - | --A certificate issued by a CA to an -end entity (for example the user of a WID) who may use it -to demonstrate their ownership of the key pair associated with it - | -
-Cross Certificate - | --A certificate issued by a CA which certificates another -CA's root certificate. This is way of uniting two distinct certification hierarchies. - | -
-Decryption - | --The process of turning encrypted data (called ciphertext) into the original information (called plaintext) -using a cryptographic algorithm parameterised with a key. - | -
-Digital Signature - | -
-A structure linking some data and a private key. A digital signature may be generated by the application of a
-private key 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.
- Digital signatures have two primary uses: to demonstrate someone's identity by signing some challenge, as in -client authentication in TLS, in which the client -signs a hash 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 -WMLScript Crypto API SignText function. - |
-
-Digital Signature Algorithm (DSA) - | --NIST-approved asymmetric algorithm. It can only be used for generating and -verifying digital signatures, not for encryption. - | -
-Elliptic Curve Cryptography (ECC) - | --Elliptical curve cryptography (ECC) is an asymmetric algorithm - 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. - | -
-Encryption - | --The process of turning meaningful data (called plaintext) into meaningless gibberish (called ciphertext) -using a cryptographic algorithm parameterised with a key. - | -
-End Entity - | --A leaf node in a certification hierarchy: any entity in a PKI -which has a certificate, but is not allowed to issue its own certificates. - | -
-Hash - | --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. - | -
-HMAC - | --Keyed-Hashing for Message Authentication. A mechanism for message authentication using cryptographic -hashes. It can be used with any iterative cryptographic -hash function, e.g., MD5, SHA-1, in combination with a secret shared key. -The cryptographic strength of HMAC depends on the properties of the underlying hash function. - | -
-ICC - | --Integrated Circuit Card: removable card with at least data storage and sometimes processing - | -
-IPSec - | --A standard providing secrecy and authentication 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. - | -
-MD2 - | --Legacy hash algorithm. Considered insecure. - | -
-MD5 - | --Legacy hash algorithm. Considered vulnerable. - | -
-Message Digest Algorithm - | --Same thing as a hash algorithm. - | -
-Nonrepudiation - | --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. - | -
-Online Certificate Status Protocol (OCSP) - | --A protocol enabling a relying party to check that a -certificate has not been revoked. In this protocol the OCSP client -asks the OCSP server about the status of one or more certificates, and receives a -digitally signed response. - | -
-Out Of Band - | -
-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.
- A common example of an out of band channel is a motorcycle courier. - |
-
-Padding - | --The process of adding bytes to the input to a block cipher so that the input matches the -block size. - | -
-Plaintext - | --The output of an decryption operation, or -the input to a encryption operation. - | -
-Pretty Good Privacy (PGP) - | --A very widely-used encryption and digital signing -program. - | -
-Private Key - | --In the context of public key cryptography, the private half of the key pair. - | -
-Public Key - | --In the context of public key cryptography, the public half of the key pair. - | -
-Public Key Certificate - | --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. - | -
-Public Key Cryptography - | --A common application of asymmetric cryptography in which one half of the key pair is -kept secrect (the private key) and the other half is published -(the public key. - | -
-Public Key Infrastructure - | -
-
- A way of modelling real-world trust relationships which enables users of public key cryptography -to have confidence in the ownership of -the public keys they are using. - -A PKI consists of: -
The TTP uses its signing key pair to create certificates for other entities, which relying parties can use to authenticate these -other entities. - We can classify PKIs according to whether they are hierachical or flat. In hierachical PKIs, such as the one defined in the PKIX -set of standards, there is a distinction between users of the PKI such as End Entities and -Relying Parties, and entities responsible for issuing and distributing certificates such as -CAs and RAs. In a flat PKI such as the -web of trust underpinning PGP, there are no entities whose -sole role is to issue certificates; instead users of the PKI certify each other. - |
-
-Registration Authority - | --An organization responsible for registering new certificate users in a -PKI, e.g. by gathering and verifying information which identifies the -certificate applicant. - | -
-Revocation - | --The term used for asserting that a certificate is no longer valid: for example, because the private key -associated with it has been compromised. - | -
-Relying Party - | --An entity who relies on the authenticity of a public key. - | -
-Root Certificate - | --The certificate of a trusted third party. -A certificate directly trusted by a relying party: 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 out of band means. A root certificate may or may not be self signed. - | -
-Secrecy - | --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. - | -
-Secure Hash Algorithm 1(SHA-1) - | --A widely used hash algorithm, producing a 160-bit digest. - | -
-Secure Sockets Layer (SSL) - | --Precursor to TLS. SSL has been through three versions: -the first two are considered insecure, and the third is almost identical to TLS. - | -
-Server Authentication - | --In a secure client-server protocol such as TLS, the process in which the server -authenticates itself to the client, so the client knows who it's talking to. - | -
-SignText - | --A function defined in the WMLScript Crypto API which provides application-level -Authentication and Nonrepudiation for transactions. - | -
-Stream Cipher - | --A class of symmetric algorithm 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. - | -
-Symmetric Cryptography - | -
-A form of cryptography in which the same key is used for encryption and decryption
- -Symmetric cryptography is fast, but suffers from the problem of how to distribute the key privately. -Asymmetric cryptography 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. - |
-
-Transport Layer Security (TLS) - | -
-A client-server security protocol providing secrecy and optionally authentication, and
-running over TCP/IP.
- In this protocol a client connects to a server; the two then perform a handshake in which they exchange a -symmetric key by using asymmetric cryptography, -which is then used to encrypt their communications, providing the secrecy element. - 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 -server authentication, in which the client establishes who the server is, and -client authentication in which the server establishes who the client is. - |
-
-Trusted Third Party (TTP) - | -
-An entity whose public key is known to a relying party due to its having been
-received via out of band means, and which is trusted to issue
-public key certificates for other entities not directly known to the relying party.
- A CA is a type of TTP. - |
-
-Web of Trust - | --The set of social relationships between users of PGP that enables them to sign each others' keys, -essentially providing a PKI for this technology. - | -
-WMLScript Crypto API - | --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 SignText - | -
-WTLS - | --A client-server security protocol providing secrecy and optionally authentication, -running at the transport layer of the WAP stack. WTLS is closely modelled on TLS, -and defines its own lightweight certificate format. - | -
-X.509 Certificate - | --A widely used type of public key certificates, part of the -now largely moribund X.500 series of standards. - | -
A | |
@anchor AES AES | -Advanced Encryption Standard -- The new conventional symmetric @ref block_cipher "block cipher" chosen by NIST as a - replacement for @ref DES. It can process 128-bit data blocks using - cipher keys with lengths of 128, 192, or 256 bits. |
@anchor ASN ASN.1 | -Abstract Syntax Notation 1 (See: ASN.1, - ISO/IEC 8824, and ISO/IEC 8825.) -- A data specification meta-language widely used in @ref public_key_cryptography "public key cryptography" - standards. (Also of interest: A Layman's Guide to - a Subset of ASN.1, BER, and DER.) |
@anchor asymmetric @anchor Asymmetric Asymmetric Cryptography | -A form of cryptography in which the 'key' is generated as a key pair: if one key is used for @ref encryption only the - other can be used to decrypt, and vice versa. \n\n - Using asymmetric cryptography, the problem of key distribution becomes one of @ref authentication; i.e. how to make sure - that a given key really does belong to the entity that claims to own it. See: - @li @ref asymmetric_cryptography - @li @ref SS_Cryptalg_asymmetric_ciphers. |
@anchor attribute_cert Attribute Certificate | -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. - |
@anchor authentication @anchor Authentication Authentication | -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. |
B | |
@anchor BER BER | -Basic Encoding Rules for @ref ASN "ASN.1", as defined in X.690. (Also of interest: - A Layman's Guide to a Subset of ASN.1, BER, and DER.) - |
@anchor block_cipher Block Cipher | -A class of symmetric algorithm 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 @ref plaintext is split up into appropriately-sized - blocks and each block is fed into the cipher. |
C | |
@anchor CA CA | -Certification Authority -- An organisation that performs the following functions in a hierachical @ref PKI: - @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 - out-of-band means. - @li certifying End Entities (@ref EE "EE"s) by generating and distributing certificates for them. The certified @ref EE is the - subject of the @ref certificate; the CA is the issuer. The CA validates the certificate holder's identity and 'signs' - the @ref certificate so that it cannot be tampered with or forged. The @ref certificate issued by the CA binds a particular - @ref public_key "public key" to the name of the @ref EE the @ref certificate identifies. - @li supporting certificate revocation and revocation checking: if an @ref EE suspects that their key has been compromised, - they can contact the CA that issued it, who will then revoke their @ref certificate. - - 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" - channels. This key pair is not logically certified by anything, but it is usually distributed inside a self-signed - @ref certificate to afford some degree of tamper evidency. \n\n - 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 that in turn are used to certify End Entities. Also, CAs may certify the signing keys - of other CAs by issuing cross certificates, which enable interoperation between two distinct @ref PKI "PKI"s. |
@anchor CA_certificate CA Certificate - | A @ref certificate held by a @ref CA: the key pair associated with it is used for signing certificates issued by that - @ref CA. May or may not be self-signed. |
@anchor CBC CBC | -Cipher Block Chaining -- A cryptographic mode for @ref block_cipher "block ciphers". It is an @ref encryption method that protects - against block replay attacks by making the encryption of a cipher block dependent on all blocks that precede it. - Before it is encrypted, the @ref plaintext is XORed with the previous @ref ciphertext block (which has been stored in a - feedback register). After the encryption, the resulting ciphertext is again stored in the feedback register, to - be XORed with the next plaintext block, and so on until the end of the message. |
@anchor certificate @anchor certificates Certificate | -For our purposes, this is the same thing as a @ref public_key_certificate "public key certificate". |
@anchor ciphermode Ciphermode | -description |
@anchor ciphertext Ciphertext | -The output of an @ref encryption operation, or the input to a @ref decryption operation. |
@anchor CLDC CLDC | -J2ME Connected Limited Device Configuration -- Serves the market consisting of personal, mobile, and - connected information devices. This configuration includes some new classes designed specifically to fit the - needs of small-footprint devices. |
@anchor client_authentication Client Authentication | -In a secure client-server protocol such as @ref TLS, the process in which the client authenticates itself to - the server, so the server knows who it's talking to. \n See @ref WTLS_client_authentication "client authentication in WTLS". |
Client/User/End Entity Certificate | -A @ref certificate issued by a @ref CA to an end entity, @ref EE, who may use it to demonstrate their - ownership of the key pair associated with it. |
@anchor CRL CRL | -Certificate Revocation List -- A list of (identifiers for) @ref certificates that have been revoked by a - particular @ref CA. The use of CRLs is for maintaining access to servers in a network, in a @ref PKI; in some cases, - @ref OCSP has superseded CRL. See: - @li RFC2459 - -- Internet @ref X509 "X.509" @ref PKI Certificate and CRL Profile - @li RFC3279 - -- Algorithms and Identifiers for the Internet @ref X509 "X.509" @ref PKI Certificate and Certificate Revocation List - (@ref CRL) Profile - @li RFC3280 - -- Internet @ref X509 "X.509" @ref PKI Certificate and Certificate Revocation List (@ref CRL) Profile. - |
@anchor cross_certificate Cross Certificate | -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 - certification hierarchies. |
D | |
@anchor decryption Decryption | -The process of turning encrypted data (called @ref ciphertext) into the original information (called - @ref plaintext) using a cryptographic algorithm parameterised with a key. |
@anchor DER DER | -Distinguished Encoding Rules -- A set of rules for encoding @ref ASN "ASN.1" data structures as a byte stream, which - has the property that any given @ref ASN "ASN.1" data structure will always encode to the same byte stream. DER is a - subset of @ref BER. (Also of interest: - A Layman's Guide to a Subset of ASN.1, BER, and DER.) - |
@anchor DES DES | -Data Encryption Standard -- A symmetric @ref block_cipher "block cipher" (that is the U.S. and international standard) used for - @ref encryption and @ref decryption. A 64-bit block cipher with a 56-bit key organized as 16 rounds of operations. |
@anchor digital_signature Digital Signature | -A structure linking some data and a @ref private_key "private key". A digital signature may be generated by the application of a - private key to some piece of data. The original data may be reconstructed by applying the corresponding @ref public_key "public key", - demonstrating that the signature could only have been generated by someone with access to the private key.\n\n - Digital signatures have two primary uses: to demonstrate someone's identity by signing some challenge, as in - @ref client_authentication "client authentication" in @ref TLS, in which the client signs a @ref hash 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 @ref WMLScript Crypto API SignText function.\n\n - See: an introduction to @ref Security_signatures. |
@anchor DN DN | -Distinguished Name -- An @ref ASN "ASN.1" structure containing various attributes (name-value pairs) that together - uniquely identify the entity for certification purposes. \n\n - The name used in @ref X509_certificate "X.509 certificates" is the X.500 Distinguished Name, which describes a path - through an X.500 Directory Information Tree. Conventionally, a DN comprises at least three attributes: a user's - 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 - (e.g., \c c=GB ). - |
@anchor DSA DSA | -Digital Signature Algorithm -- A NIST-approved @ref asymmetric algorithm. It can only be used for generating - and verifying @ref digital_signature "digital signatures", not for @ref encryption. - See: The Digital Signature Standard. - |
E | |
@anchor ECB ECB | -Electronic Codebook -- A cryptographic mode for @ref block_cipher "block ciphers". It is a mode that encrypts - blocks of @ref plaintext to corresponding blocks of @ref ciphertext. Given use of the same key, a block of plaintext - will always encrypt to the same block of ciphertext. |
@anchor ECC ECC | -Elliptical Curve Cryptography -- An @ref asymmetric @ref encryption technique based on elliptic curve theory that - can be used to create faster, smaller, and more efficient cryptographic keys. |
@anchor encryption Encryption | -The process of turning meaningful data (called @ref plaintext) into meaningless gibberish (called @ref ciphertext) - using a cryptographic algorithm parameterised with a key. |
@anchor EE EE | -End Entity -- A leaf node in a certification hierarchy: any entity in a @ref PKI which has a @ref certificate, but is - not allowed to issue its own certificates. |
F |
G |
H | |
@anchor hash Hash | -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 that produce the same output. See: - @li @ref cryptographic_hash - @li @ref SS_Cryptalg_hash_algorithms. |
@anchor HMAC HMAC | -Keyed-Hashing for Message Authentication -- A mechanism for message @ref authentication using cryptographic hashes. It - can be used with any iterative cryptographic @ref hash function, e.g., @ref MD5, @ref SHA "SHA-1", in combination with a secret - shared key. The cryptographic strength of HMAC depends on the properties of the underlying @ref hash function. |
I | |
@anchor ICC ICC | -Integrated Circuit Card -- A removable card with at least data storage and sometimes processing. |
@anchor IPSec IPSec | -IP Security Protocol -- A standard providing @ref secrecy and @ref authentication at the network or - datagram layer of network communication. IPSec is mandatory in IPv6. \n - See: IPSec Working Group. |
J |
K |
L |
M | |
@anchor MD2 MD2 | -Legacy @ref hash algorithm. Considered insecure. |
@anchor MD5 MD5 | -Legacy @ref hash algorithm. Considered vulnerable. |
@anchor message_digest_algorithm Message Digest Algorithm | -Same as a @ref hash algorithm. |
@anchor MIDP MIDP | -Mobile Information Device Profile (JSP-118). - -- A set of Java APIs that is generally implemented on the @ref CLDC "Connected Limited Device Configuration" (CLDC). - It provides a basic J2ME application runtime environment targeted at mobile information devices, such as - mobile phones and two-way pagers. The MIDP specification addresses issues such as user interface, persistent storage, - networking, and application model. |
N | |
@anchor nonrepudiation Non-repudiation | -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. |
O | |
@anchor OAEP OAEP | -Optimal Asymmetric Encryption Padding -- OAEP is a method for encoding messages, and addresses a potential - vulnerability in PKCS#1. Padding means extra - bits concatenated with a key, password, or @ref plaintext. @ref Padding helps against dictionary attacks. |
@anchor OCSP OCSP | -@ref X509 "X.509" Internet Public Key Infrastructure Online Certificate Status Protocol -- A simple request/response - protocol. To establish whether a given @ref certificate or list of certificates has/have been revoked, a client forms an - OCSP request and sends this to an OCSP server. The server maintains revocation information in the form of, say, - Certificate Revocation Lists (@ref CRL "CRL"s). The server replies to the client with a signed OCSP response, stating for - each certificate whether the status is Good, Revoked, or Unknown. This response in turn is checked to ensure that it - is valid, and that it is from an entity trusted for performing revocation checking. - See: - @li RFC2560 - -- @ref X509 "X.509" Internet @ref PKI Online Certificate Status Protocol - OCSP - @li @ref overview_OCSP overview. |
@anchor OID OID | -Object Identifier -- A universal constant uniquely associated with an object type used in @ref ASN "ASN.1". |
@anchor OS OS Element | -A discrete, identifiable entity within a ROM file that implements a set of interfaces. Examples of - OS Elements include independently instantiable classes within DLLs, bitmaps within an MBM file, resource - entries within a resource file. An OS Element identifies a part of a ROM file that could in principle be - factored out or removed if it becomes architecturally advisable. |
@anchor out_of_band Out Of Band | -A channel of communication that 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. - A common example of an out of band channel is a motorcycle courier. - |
P | |
@anchor Padding @anchor padding Padding | -Extending the size of a block of @ref plaintext to, say, a 64-bit block by addition of a regular or random pattern. - For example, for use with @ref ECB. See: - @li @ref rsa_padding - @li @ref symmetric_ciphers. |
@anchor PKCS PKCS | -Public-Key Cryptography Standards. |
PKCS#10 | -@ref PKI standard that describes how to construct @ref certificate requests. |
@anchor PKG PKG file | -A text file that defines a @ref SIS file. The PKG file is passed to the MAKESIS tool to produce the - @ref SIS file. |
@anchor PKI PKI | -Public Key Infrastructure -- A way of modelling real-world trust relationships that enables users of - @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: - @li a trusted third party (@ref TTP) - @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" - @li a means of distributing other certificates to @ref relying_party "relying parties" - @li arrangements for the @ref revocation and renewal of these certificates - @li certificate management and validation software on the @ref relying_party "relying party's" computer - - The TTP uses its signing key pair to create certificates for other entities, which relying parties can use to - authenticate these other entities. - - We can classify PKIs according to whether they are hierachical or flat. In hierachical PKIs, such as the one defined - in the PKIX set of standards, there is a distinction between users of the PKI such as End Entities (@ref EE "EE"s) and - @ref relying_party "relying parties", and entities responsible for issuing and distributing certificates such as @ref CA "CA"s and - @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 - to issue certificates; instead users of the PKI certify each other. |
@anchor PKIX PKIX | -Public-Key Infrastructure (X.509) -- A profile of @ref X509 "X.509" for the internet. See: - @li @ref Certman_X509_Certificate_Validation - @li RFC2459 - -- Internet X.509 Public Key Infrastructure Certificate and CRL Profile.) |
@anchor plaintext Plaintext | -The output of an @ref decryption operation, or the input to a @ref encryption operation. |
@anchor PGP PGP | -Pretty Good Privacy -- A very widely-used @ref encryption and digital signing program. |
@anchor private_key Private Key | -In the context of @ref public_key_cryptography "public key cryptography", the private half of the key pair. |
@anchor public_key Public Key | -In the context of @ref public_key_cryptography "public key cryptography", the public half of the key pair. |
@anchor public_key_certificate Public Key Certificate | -A digitally signed structure including at least an identifier for an individual entity and a @ref public_key "public key", whose - function is to bind the entity with the key. |
@anchor public_key_cryptography Public Key Cryptography | -A common application of @ref asymmetric cryptography in which one half of the key pair is kept secrect - (the @ref private_key "private key") and the other half is published (the @ref public_key "public key"). See: - @li @ref asymmetric_cryptography - @li @ref Security_intro_PKC. |
Q |
R | |
@anchor RA Registration Authority | -An organization responsible for registering new @ref certificate users in a @ref PKI, e.g. by gathering and verifying - information which identifies the @ref certificate applicant. |
@anchor revocation Revocation | -The term used for asserting that a @ref certificate is no longer valid: for example, because the @ref private_key "private key" - associated with it has been compromised. |
@anchor relying_party Relying Party | -An entity who relies on the authenticity of a @ref public_key "public key". |
@anchor root_certificate Root Certificate | -The @ref certificate of a @ref TTP "trusted third party". A certificate directly trusted by a @ref relying_party "relying party" - 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 @ref out_of_band "out of band" means. A root certificate may or may not be self signed.\n\n - See: @ref certman_certstore_root_cert_management. |
@anchor RSA RSA | -A @ref public_key "public key" algorithm used for both @ref encryption and @ref digital_signature "digital signatures", named after its creators: - Rivest, Shamir, and Adleman. |
S | |
@anchor secrecy Secrecy | -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. |
@anchor SHA SHA-1 | -Secure Hash Algorithm 1 -- A widely used @ref hash algorithm, producing a 160-bit digest. |
@anchor server_authentication Server Authentication | -In a secure client-server protocol such as @ref TLS, the process in which the server authenticates itself to the - client, so the client knows to whom it's talking. \n See: @ref WTLS_server_authentication "Server authentication in WTLS". |
@anchor SignText SignText | -A function defined in the @ref WMLScript Crypto API that provides application-level @ref authentication and - @ref nonrepudiation "non-repudiation" for transactions. |
@anchor SIS SIS file | -A binary package file containing all the files for an installation, as well as metadata describing which - directory to install them into, dependencies, etc..\n - See: @ref overview_SWI overview. |
@anchor Stub SIS Stub file | -A @ref SIS file containing only the metadata, and not the files. After the installation, this file is archived - on the device for uninstallation purposes, etc.. |
@anchor SMIME S/MIME | -Secure/Multipurpose Internet Mail Extensions - -- Provides a consistent way to send and receive secure MIME data. S/MIME provides the following cryptographic - security services for electronic messaging applications: @ref authentication, message integrity and @ref nonrepudiation "non-repudiation" of - origin (using @ref digital_signature "digital signatures") and privacy and data security (using @ref encryption); see - RFC2633 -- S/MIME Version 3 Message Specification. - |
@anchor SSL SSL | -Secure Sockets Layer -- A protocol for securing network connections that provides @ref authentication, @ref encryption, and - data integrity using @ref PKI "Public Key Infrastructure" (PKI). Precursor to @ref TLS. SSL has been through three versions: - the first two are considered insecure, and the third is almost identical to @ref TLS. |
@anchor stream_cipher Stream Cipher | -A class of symmetric algorithm that is initialised with a key, then outputs a stream of pseudorandom bits. - This 'keystream' is typically XOR-ed with the @ref plaintext to generate the @ref ciphertext. So they encrypt a bit of - plaintext at a time. |
@anchor symmetric_cryptography Symmetric Cryptography | -A form of cryptography in which the same key is used for @ref encryption and @ref decryption.\n\n - Symmetric cryptography is fast, but suffers from the problem of how to distribute the key privately. @ref Asymmetric - cryptography is an attempt to alleviate the key distribution problem, by reducing the requirement for the distributed - key from one of privacy to one of @ref authentication. See: - @li @ref symmetric_ciphers - @li @ref SS_Cryptalg_symmetric_ciphers. |
T | |
@anchor TLS TLS | -Transport Layer Security -- A protocol that provides communications secrecy, and optionally @ref authentication, - over the Internet TCP/IP. The protocol allows client/server applications to communicate in a way that is designed to - prevent eavesdropping, tampering, or message forgery. - - In this protocol a client connects to a server; the two then perform a handshake in which they exchange a - symmetric key by using @ref asymmetric cryptography, which is then used to encrypt their communications, - providing the @ref secrecy element. Without the @ref authentication element, @ref 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 @ref WTLS_server_authentication "server authentication", in which the client establishes who the server is, and - @ref client_authentication "client authentication" in which the server establishes who the client is. \n\n - See: RFC2246 -- - The TLS Protocol). TLS is the successor to the @ref SSL "Secure Sockets Layer" (SSL). (Also, see: @ref WTLS.) |
@anchor TTP TTP | -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 - 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 - known to the relying party. A @ref CA is a type of TTP. |
U | |
@anchor URI URI | -Uniform Resource Identifier -- A way to identify some content on the Internet, typically through the use of an - identifier for the scheme (e.g. HTTP) through which the content may be accessed, and an identifier for the - content that makes sense within that scheme. - The most common form of URI is a Web page address, which is a particular form or subset of URI called a Uniform - Resource Locator (URL). |
V |
W | |
@anchor WAP WAP | -Wireless Application Protocol -- A secure specification - that enables users to access information instantly using devices such as mobile phones, pagers, two-way radios, - smartphones and communicators. The WAP defines a set of protocols in transport, security, transaction, session, and - application layers to enable the creation of advanced mobile services. |
@anchor web_of_trust Web of Trust | -The set of social relationships between users of @ref PGP that enables them to sign each others' keys, essentially - providing a @ref PKI for this technology. |
@anchor WIM WIM | -Wireless Identity Module - -- Used in performing @ref WTLS and application level security functions, and especially, to store and process - information needed for user identification and @ref authentication. Examples of WIM implementations are a Subscriber - Identity Module (SIM) card or an external smart card. |
@anchor WMLScript WMLScript Crypto API | -A @ref WAP Forum standard that defines cryptographic functions in WML, the scripting language used in @ref WAP. - It defines a function for creating signed objects called @ref SignText. |
@anchor WTLS WTLS | -Wireless Transport Layer Security - -- The security layer of the @ref WAP, providing privacy, data integrity and @ref authentication for WAP services. - It is a @ref WAP variant of @ref TLS and defines its own lightweight @ref certificate format. \n\n - See: @ref overview_WTLS overview. |
@anchor WTLS_certificate WTLS certificate | -@ref WAP variant of @ref X509_certificate "X.509 certificates".\n\n - See: @ref overview_WTLS overview. |
X | |
@anchor X509 X.509 | -A widely used standard for digital certificates. See: - @li @ref Certman_X509_Certificate_Validation - @li RFC2459 - -- Internet @ref X509 "X.509" @ref PKI Certificate and @ref CRL Profile - @li RFC3280 - -- Internet @ref X509 "X.509" @ref PKI Certificate and @ref CRL "Certificate Revocation List" Profile. - |
@anchor X509_certificate X.509 certificate | -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 - 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 - attribute data such as identifying names. A hierarchy of certificates is often used tracing back to a single root - @ref CA_certificate "CA certificate". If a user trusts the @ref CA, then they can trust that the @ref certificate belongs to the - person/company given within the certificate. Using the public key within the certificate, they can then verify that - other data has originated from the certificate owner via the use of @ref digital_signature "digital signatures" created using the corresponding - @ref private_key "private key". @ref X509 "X.509" basically defines the certificate format. |
Y |
Z | |
@anchor zlib zlib | -zlib is designed to be a free, general-purpose, legally unencumbered (i.e., not covered by any patents) lossless - data-compression library for use on virtually any computer hardware and operating system. zlib was written by - Jean-loup Gailly (compression) and Mark Adler (decompression). See: - @li RFC1950, zlib format - @li RFC1951, deflate format - @li RFC1952, gzip. |