WO2001099380A1 - Negociation entre dispositifs de chiffrage destinee a etablir des parametre pour la communication - Google Patents

Negociation entre dispositifs de chiffrage destinee a etablir des parametre pour la communication Download PDF

Info

Publication number
WO2001099380A1
WO2001099380A1 PCT/GB2001/002680 GB0102680W WO0199380A1 WO 2001099380 A1 WO2001099380 A1 WO 2001099380A1 GB 0102680 W GB0102680 W GB 0102680W WO 0199380 A1 WO0199380 A1 WO 0199380A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
communications
parameters
cryptographic
devices
Prior art date
Application number
PCT/GB2001/002680
Other languages
English (en)
Inventor
Martyn Gilbert
Original Assignee
Amino Holdings Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Amino Holdings Limited filed Critical Amino Holdings Limited
Priority to AU2001274243A priority Critical patent/AU2001274243A1/en
Publication of WO2001099380A1 publication Critical patent/WO2001099380A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols

Definitions

  • This invention relates to a method of carrying out secure and verifiable communication and in particular to a method for secure and verifiable communication through an electronic data network.
  • Another related problem is the need to confirm that information genuinely originates from the purported sender and has not been altered in transit .
  • a digest or signature may be sent together with the message, the digest or signature being encrypted and derived from the message itself so that the decrypted signature or digest allows the origin and content of the message content to be verified whether the content itself was encrypted or not.
  • This invention is intended to overcome these problems, at least in part .
  • this invention provides a .communications method for communicating between first and second encryption devices in which a distribution mechanism for each of three elements of a communications flow in each direction between the encryption devices is stored by the first encryption device, the three elements of the communications flow being an access control element, an information content element and a verification element and each distribution mechanism defining the following parameters: means of distribution; minimum required bandwidth; maximum permitted bandwidth; maximum permitted latency; minimum cryptographic strength; acceptable cryptographic algorithms; hierarchical parent; source specification; destination specification; wherein, before communication can take place the first and second encryption devices negotiate to establish a set of parameters for the communications flow which can be supported between the devices and comply with the distribution mechanism stored by the first device and if a set of parameters is established the first device allows communication between the devices using the established set of parameters.
  • this invention provides software able to carry out the above method.
  • information is to be transferred from a source to a receiver with the information being encrypted or at least validated or verified regarding its source and content .
  • validate and verify are used synonymously.
  • the originator employs a cryptographic encoder to encrypt the information and generate a message incorporating the encrypted information.
  • the client will require a software smart token able to decrypt the received message so that its information content can be accessed and/or verified.
  • the software smart token will be held within or operated by a dedicated hardware device such as a plug in smart card carrying the smart token. In any event, the smart token will be operating within some hardware which may or may not be dedicated.
  • the cryptographic encoder and the client hardware operating or containing the smart token will be connected to one another through an electronic communications network. Communications over such a network will be controlled by a network communications protocol such as the Internetworking protocol (IP) .
  • IP Internetworking protocol
  • this information transfer function is the service provided using the method.
  • originator is used to refer to the person setting the service specification which ultimately controls all services provided and whether the service is provided.
  • the originator when an originator wishes to provide a service using the invention, the originator must supply a service specification to a cryptographic encoder.
  • the service specification must contain specifications of all distribution mechanisms used to provide the service as will be explained below.
  • the service specification may also define the format of the received and delivered information and other management instructions and commands but these are not part or present invention.
  • a would be end user must first register using a smart token.
  • negotiations will take place between the smart token and the cryptographic encoder to determine whether the service is to be provided and the communications parameters for provision of the service. Subsequently, when the user wishes to access the service the user must make an access request using the smart token and the service will be provided.
  • the access request phase may include further negotiation between the smart token and the cryptographic encoder to confirm that the previously agreed parameters can still be supported. Further, where a range of parameters is agreed in the registration step, negotiation can take place to decide which parameters of the range will be used.
  • a service to be provided by an originator to a client may just be the one off provision of a single piece of information.
  • a service will involve the provision of multiple items of information over a period of time.
  • the originator of information to be delivered by a service must define the distribution mechanisms which may be used by the service. These must be specified for three elements of the service, the command flow, which comprises two protection structures, and the content flow. Each of these elements may be bi-directional and the two directions of each element have separately definable distribution mechanisms. As a result, the service definition must contain the specifications of at least six different distribution mechanisms .
  • the definition of at least six different distribution mechanisms is a minimum requirement, the originator could define different distribution mechanisms for different parts of any or each element of the service, giving an arbitrarily large number of defined distribution mechanisms.
  • the two protection structures are a first access control structure containing the necessary access keys to allow decoding and a second authentication structure containing any required signature.
  • the service specifications are the specifications required to take clear text information from one party (the originator) , encrypt it, and subsequently deliver the decrypted clear text information to an end point (the client or end user) .
  • the client is able to use the received information as they wish.
  • Ciphertext Transport Specification In order to allow the information regarding service to be provided, the information originator must define the six distribution mechanisms of the service. These definitions are provided to the cryptographic encoder.
  • each service has six distribution mechanisms, which must be specified to define the service, it may be that some of these distribution mechanisms are not actually required by a particular service. These distribution mechanisms which are not required are given a "null" specification.
  • the end user When a user or client wishes to access information through the service, the end user must contact the cryptographic encoder. The cryptographic encoder will then negotiate with a smart token of the access equipment being employed by the end user to allow service registration to take place .
  • communications protocols will allow messages to be sent by several different means of distribution such as unicast (point to point connection), multicast or broadcast.
  • the originator must specify for each information providing service which of these means of distribution may be used for each of the distribution mechanisms making up the service.
  • Each distribution mechanism may allow one or more means of distribution to be used to distribute the information.
  • the end user access equipment In order for registration to proceed, the end user access equipment must be able to support one of the specified means of distribution, and negotiation between the cryptographic encoder and the end user access equipment will select a specified and mutually supported means of distribution for each distribution mechanism.
  • the end user access equipment will establish the currently available bandwidth capability and the latency of the current end user access equipment by obtaining the parameter values facilitated by the current user access equipment from the support software of the access equipment.
  • the support software may have the end user access equipment "ping" the remote cryptographic encoder so that that portion of the transport latency can be estimated.
  • bandwidth and latency for the current user end user access equipment will depend not only on the hardware and software of the end user access equipment itself but also on the properties of the communication links between the cryptographic encoder and the end user access equipment .
  • the cryptographic encoder will take the current bandwidth capability and latency of the end user access equipment and compare these to the minimum and maximum bandwidths and maximum latency set in the distribution mechanism specifications.
  • the cryptographic encoder may refuse to provide the service, the cryptographic encoder may provide the service together with a warning that satisfactory communication may not be possible or the cryptographic decoder may offer an alternative service.
  • the entire service registration negotiation process takes place by way of a root dialogue between the cryptographic encoder and the end user which is as undemanding as possible in terms of the required bandwidth, but has the highest possible cryptographic strength for the end user equipment being employed.
  • this negotiation root dialogue is not satisfactorily supported, negotiations will not be possible and no services will be available.
  • a smart token may be used for service registration from one end user access device and that the same smart token may be used later with a different access device after registration to access the requested services. If this occurs, the cryptographic registration process will have to be repeated to determine whether the new access device is capable of satisfying the negotiated service parameters.
  • the assessment of the cryptographic strength supported by end user device is largely subjective because it depends on the resources which are estimated to be necessary to determine the keys used for encryption. This estimate is based on the assumption that the encryption algorithms used are themselves in the public domain, but this will normally be the case.
  • the parameters determining the cryptographic strength will be negotiated between the cryptographic encoder, based on the specification set by the service originator, and the user access device, using the smart token if required.
  • the necessary parameters may include whether the communication will be in clear or symmetrically or asymmetrically encrypted, the key length of the encryption key to be used and the validity period of the key used.
  • the acceptable cryptography algorithms is a listing of the algorithms deemed acceptable for providing the service by the originator. This may be an exclusive list of algorithms making the use of one of the listed algorithms mandatory. Alternatively, the identification of acceptable cryptographic algorithms may be left blank and selection of an appropriate algorithm left to negotiation between the cryptographic decoder and the user access device. In this case, the cryptographic algorithm used will normally be first algorithm identified in the negotiation which both satisfies the cryptographic strength of the distribution mechanism specification and can be implemented by the cryptographic encoder and the end user device .
  • the cryptographic encoder will itself have to maintain a listing of supported cryptographic algorithms independently of any list defined for specific services, and any algorithms to be defined in the specification of services will have to be algorithms supported by the cryptographic decoder.
  • the cryptographic strength and acceptable algorithms for the distribution mechanisms of the service are separately specified because the cryptographic strength will depend upon the cryptographic algorithm used. Accordingly, the judgement is to whether the cryptographic strength requirement is met is judged based upon the use of the weakest cryptographic algorithm which will be available for use. If a stronger algorithm is used, it will automatically follow that the cryptographic strength requirement is met.
  • the information content itself may be transmitted with a relative weak but fast encryption or the information content itself may be transmitted in clear without any encryption at all.
  • a signature is also sent which validates the received information content to the user.
  • the signature will be encrypted and contain information derived from the accompanying information content so that the decrypted signature can be compared with information derived from the received information content to confirm that the received information content is correct.
  • the signature can be a cyclic redundancy check derived from the information content and asymmetrically encrypted within a public key encryption infrastructure. This will require that the signature and the information content itself are treated differently and it is intended that the signature will be transmitted within the command flow element of the service while the information content is transmitted within the content flow of the service. Where the information content is not encrypted, the specified distribution mechanism for the information content transmission part of the service will have a minimum cryptographic reference strength of none and acceptable cryptographic algorithms will be defined as clear.
  • time stamping may be needed in order to ensure that the signature can be tagged to the content to which it applies.
  • streaming video may be transmitted at variable bit rates which can cause difficulties in identifying when a certain amount of data has been generated. This is only an example and there are other situations where time stamping may be required or desirable.
  • Access keys to allow information content and any signature to be decrypted must be provided to a user before the information content or signature itself, while any authenticating signature authenticating a content will be transmitted after the content itself. As a result, there will always be some non zero latency between the content and signature. It is because of this consideration that the control element of the service has two protection structures, one protection structure for access control providing the necessary access keys and the other to carry signatures.
  • the part of the service definition relating to the signature protection structure of the command flow can be defined as a null specification.
  • the hierarchical parent identifies for each distribution mechanism other service specifications which can be used to provide an encryption key for the distribution mechanism.
  • the hierarchical parent mechanism by which one service is able to provide an encryption key for another service having a different service specification is the mechanism by which encryption key distribution and ITSEC6 traceability is provided .
  • asymmetric cryptography is used to carry out public key infrastructure (PKI) encryption schemes.
  • PKI public key infrastructure
  • TTP trusted third party
  • the private key will always be held within the smart token, while the necessary public keys are held in the cryptographic encoder.
  • the smart token and cryptographic encoder are themselves secure against cryptographic attack so that the keys they provide can be trusted by the originator and the end user so that the hierarchy used to issue the keys can be as flat or as tall as the originators and users require .
  • DRM digital rights management
  • the use of the hierarchical parent mechanism allows the encryption keys needed by a service to be provided by another more secure service. For example, two way cryptography will normally be faster to apply than one way cryptography so that two way cryptography is normally more applicable to high bandwidth services. However, there is a considerable problem of key distribution in such two way cryptography approaches. However, by using the hierarchical parent mechanism, a high bandwidth service using two way cryptography can nominate a lower band width but more secure system such as a PKI scheme as its hierarchy parent. This parent service can then be used to provide the necessary encryption keys to operate the two way cryptographic service .
  • the clear text source specification specifies the source IP number, or corresponding address under other communication protocols, from which the service is provided. A single address or a number of addresses may be specified. Only data from the specified address or addresses is considered to constitute the defined service. Any external applications must send data to or through the specified addresses for this data to be carried by the service.
  • the clear text source specification of a distribution mechanism specification for the return part of a service may specify whether the initial unencrypted clear text data may originate only from a secure smart token interface or whether it may originate from other parts of the generally insecure user access device.
  • the clear text destination specification specifies the IP port number, or equivalent address for other communication protocols, of the device to which the decrypted, clear text, data is to be sent. In order to avoid compromising the security and integrity of the information this defined destination should have some private or secure connection to the decryption device, that is the cryptographic decoder or the smart token.
  • the decrypted clear text data is not to intend to be routable further beyond the specified destination because this would compromise security.
  • this may require devices containing cryptographic encoders or smart tokens to be fitted with two network adaptors, one being a dedicated adaptor for cryptographic traffic and one for other traffic.
  • Such arrangements should be used only if the service originator and end user are satisfied that the encoder or smart token cannot be subject to cryptographic attack through the second adaptor.
  • the clear text destination specification also specifies whether or not the secured data must be retained by the decoding device, or by any further host device forming the user access device. This allows the highest level of service security and permits secure caching of data by essentially providing a server within an encoder.
  • the decrypted information delivered by a service is sent to the destination IP port, or corresponding address for other communication protocols, specified in the clear text destination specification and the clear text source specification identifies the IP address and the port number, or corresponding address for other communication protocols, which should be used by the encoder as the source of the information to be encrypted.
  • the cipher text transport specification allows for the possibility of employing network diversity to increase security by taking sequential portions of the encrypted data and sending it by different network routes to a destination. This is particularly useful when the routing is being carried out through the Internet because this supports such a large number of different routes.
  • the cipher text transport specification sets the number of different routes which should be nominated to carry the service.
  • the number of routes which may be nominated for a given service in the cipher text transport specification will generally be limited to some maximum number based on the capabilities of the cryptographic encoder and supporting hardware and software and the user access device.
  • any specified route may carry any number of services.
  • the distribution mechanism specifications will not normally have any control of the number of services carried over a particular route, but the number of services which are being carried by a particular route may be controlled by the cryptographic encoder or its supporting hardware and software in order to avoid more capacity being demanded from the route than it is able to support .
  • the encrypting device will autonomously fragment the encrypted data and send it by the nominated routes.
  • the decrypting device must be equipped to support at least the number of network diversity channels employed by the encryption device, so determining the number of network diversity channels, that is number of different routes, which can be employed will be part of the initial service registration negotiations.
  • Some information originators may preset the network diversity to only make their services available at a specific diversity level. This may be used to set the diversity of their services to one so that users of that originators services only need to be able to support a diversity of one and the information path connecting them only needs to support a single route .
  • the cipher text transport specification is not an essential part of the distribution mechanism specification. It is preferred to incorporate the cipher text transport specification in the distribution mechanism specification so that network diversity can be supported if desired. However, if limitation to use of only a single information route is acceptable, the cipher text transport specification can be omitted.
  • the end user when using the information transfer method or protocol of the invention, when an end user wishes to subscribe to the service, the end user must carry out the service registration process as set out above to allow the cryptographic encoder and the user access device to negotiate a set of distribution mechanism specifications which they can both support and which are regarded as permissible by the service originator. This negotiation may determine a single set of distribution mechanism specifications or a number of them.
  • the set of distribution mechanism specifications may include ranges of parameters .
  • the cryptographic encoder and the user access device again negotiate to use one of the permissible sets of distribution mechanism specifications which were determined in the subscription phase.
  • the user may subsequently attempt to access the service through a different access device to that used during subscription. If so, the new access device must have suitable software so that it can report to the cryptographic encoder that the negotiated bandwidth and latency parameters can be satisfied. If these parameters are not satisfied, or if software to allow this to be determined is not present, the cryptographic encoder may refuse to provide the service, offer a lower grade service, or provide the service with a warning that satisfactory communication may not be possible as specified by the service provider instructions.
  • the encrypted content transferred is then supplied to a user access decryption engine, preferably a smart token.
  • the decryption engine is regularly provided with decryption keys as specified in the service distribution mechanisms specification.
  • the decryption keys can be provided within the same user access device or from an external device. Where the keys are provided by an external device, the service using the decryption engine must specify as a hierarchical parent service the service which provides the keys to the external device.
  • the decrypted data is output by means specified in the service application code. Typically, some interface means will be required to transfer data from the decryption engine to output at the specified port.
  • variable data rate video where a software decryption engine within the user access device is provided with a decryption key held in an external smart card which must be physically inserted into a slot on the access device.
  • the smart card has been previously issued the key by a PKI exchange process.
  • the smart card enabled secure video service is a hierarchical child service to the smart card PKI conditional access and must identify the smart card PKI conditional access as a hierarchical parent authorised to provide it with encryption keys.
  • the service originator delivers data to an encryption engine incorporated within the cryptographic encoder.
  • the cryptographic encoder has additional functions beyond those of the encryption engine.
  • the encryption engine will have both hardware and software elements but in some bidirectional services such as consumer auctions, lower cost software only encryption engines may be used. However, it is expected that in the majority of applications the encryption engines will have at least some hardware support to ensure the security of the system.
  • Cryptographic encoders employing the present invention are ideal third parties to provide anonymity. If a first party sends messages to the encoder IP address and port identified as the clear text source in a service speci ication, it will not be possible for any third parties to identify the intended ultimate recipient of the message but only the fact that it is has been sent to the cryptographic encoder.
  • IP address and the port number used for a particular service or to communicate with a particular ultimate recipient could leak out so that the encoder address used would be sufficient to allow the identity of the person or service being communicated with to be deduced.
  • the macro service carries the true second party/ultimate recipient address or the identity of the service to be accessed within the messages. IP packets for the macro service should be all the same size.
  • An alternative approach is to encrypt the IP and port addresses themselves.
  • the use of a macro service is preferred to the encryption of IP port addresses because the encryption of IP port addresses will reduce service performance .
  • Macro services to provide anonymity can be set up using the present invention by allowing ring fenced application written in the protected language, for example JAVA, to run within the encoders so they appear as normal address destinations and sources.
  • IP addresses and ports relate to the use of the invention in the common situation where the Internetworking protocol is employed. Where other communication protocols are employed analogous address information will be used.
  • the inventive method and protocol as explained above allows the secure and verifiable transfer of information from one point to another with the protocol being highly lexible to allow the degree of security provided to be adapted to originator and user requirements and to allow the system operating parameters to be adapted to the available equipment and communications network.
  • the communications method and protocol does not place any limits on how this information transfer functionality is actually used by the service providers or originators and end users. Considerations such as end user access rights, stored value and end user identifiers are application specific and are not addressed by the present invention. These matters are data objects to be transported by the method and protocol of the invention or are derived therefrom.
  • Devices employed to carry the invention such as the cryptographic encoder will have their own addresses which will be IP port addresses, or corresponding addresses for other communication protocols. These addresses will initially be configured locally and this configuration information must be manually provided to content or service originators so they know where to send the service specifications specifying the desired distribution mechanisms for their services .
  • a smart token will provide the core of the end users' security.
  • a smart token will provide the highest level of the hierarchy for both encryption and decryption by the end user access device or devices. That is to say, the smart token will provide the root key or keys for all cryptography algorithms employed whether these algorithms are executed within the smart token itself or elsewhere. Normally, where only some or one cryptographic algorithm is executed within the smart token itself, this will be the slowest one of the algorithms used.
  • the physical device containing the smart token is required to allow the user access device to access secure services.
  • the other parts of the user access device cannot be used to access secure services when the smart card is physically removed. This provides additional security that requests for access to a service are being made by the authorised end user rather than by someone illicitly employing the user access device. This may be particular important to the user where a charge is made based on the amount of use rather than on a subscription basis.
  • the smart token will be supplied with at least one application programming interface (API) on it.
  • This API will also confer access to hierarchically inferior applications.
  • the smart token may support a number of parallel API's. This allows the smart token to be implemented on a multi-application smart card which also carries out other applications which are not managed according to the present; invention.
  • a multi-application smart card will have the APIs of all applications accessible only via a single highest level API. This is an analogous to applications running over a conventional operating system except that in this case the application is only accessible through the operating system, that is the alternative applications on the ⁇ smart card are only accessible through the highest level API . This approach permits other applications to be protected by the security of the highest level API .
  • the smart token When a smart token is used in consumer applications, it will be necessary for the smart token to store the ISP telephone number and Internet URL of the service operator so that consumer products having their access to services controlled by the smart token such as set top boxes can be initialized prior to communication with the remote cryptographic encoder. These details will be made available to the smart token through the highest level API .
  • the service will be provided and the data stored in the user access device. Alternatively, if this is not allowed in the service specification, the requested service will not be provided.
  • any changes to the software on the interface device or the smart token should only be accepted if validated by the highest level API on the smart token.
  • each smart token contains a unique user identifier.
  • the smart token issuer provides unique identifiers for loading onto smart tokens to its customers.
  • the smart tokens are issued by the smart token issuer in a dormant form.
  • a customer of the smart token issuer wishes to issue an item containing a smart token, for example a smart card, for use by an end user
  • the smart token holds a PKI conversation with a central cryptographic encoder administered by the customer. This causes a unique end user identifier from those issued by the smart token issuer to the customer to be issued by the encoder to the card.
  • the encoder will report in encrypted form to the smart token issuer that this identifier has been issued and on which customers behalf this was done.
  • a smart token with a disabled identifier must be reactivated by the smart token issuer to allow continued use. Normally, the smart token will be re-licensed before the unique identifier is disabled and the fixed period reset to run from the re- licensing date. To ensure that the smart token is able to disable the unique identifier when necessary, the smart token is supplied with the current date and time every time it starts up communication with a cryptographic encoder to begin registration or request information transfer.
  • the use of the unique user identifiers in smart tokens is intended primarily to allow the smart token issuer to ensure that its smart token technology is not being illicitly used. Due to the encrypted nature of the communications supported on the inventive method, it would be difficult for the smart token issuer to keep track of usage of the smart tokens without this feature. However, the issue of a unique identifier to each smart token also safeguards the service providers against unauthorised access to services using fake smart tokens because these will have unissued, duplicated or out of date user identities .
  • cryptographic encoders and smart tokens will usually be used.
  • the cryptographic encoder will also carry out the function of managing the PKI hierarchy used to issue keys to the smart tokens. Further, the cryptographic encoder will report to the smart token issuer when a smart token is used to subscribe to a new service and when a smart token is used to access a service. Further, the cryptographic encoder will report to the originator or service provider the user identity when the service is newly subscribed to or accessed. The originator or service provider may themselves be operating the cryptographic encoder and in this case reporting is straightforward. Where the originator or service provider are not themselves operating the cryptographic encoder the reporting of the user ID may made directly to the originator or to the cryptographic encoder operator for forwarding to the originator as desired by the parties involved.
  • the cryptographic encoder must be able to add certificates to data for delivery to users and be able to accept and process certificates on received encrypted data. This may require encrypted data to be received, decrypted and authenticated and then re-encrypted and sent out together with a new certificate.
  • the cryptographic encoder may use an attached computer such as a standard PC for data storage if required.
  • an attached computer such as a standard PC for data storage if required.
  • any such computer used for data storage by the cryptographic encoder must be suitably protected against cryptographic attack to preserve the integrity of the cryptographic encoder, for example by providing and storing information on the PC only in encrypted form, having no network links to the PC except those going through the encoder and physically controlling access to the PC.
  • the cryptographic encoder In order to allow the operations of the cryptographic encoder to be managed, services to be provided and service definitions to be supplied to the cryptographic encoder, it will normally be necessary to have the cryptographic encoder arranged to receive instructions and supply information through its operators or the service originators. Such communication should be through cryptographically secured connections in order to maintain the integrity of the cryptographic encoders.
  • a smart token is a software device operating on the hardware of the end user access device. Usually, the smart token will be operating within dedicated hardware such as a smart card which can be physically removed from the rest of the end user access device.
  • the smart token must be capable of storing the unique user identity and must be able to store the service permissions for the end user. It must also be able to set the permission policy for a service through the customers register. It is not essential that the smart token will be able to directly support the necessary scripting language to allow the permissions policy to be set, but if it cannot, it must expose an API so that an intelligent user access device can set and interrogate the permissions.
  • a "dumb” user access device which simply comprises a serial port adaptor to enable the smart card to connect to the communications network and supplies it with a reference clock.
  • Such an arrangement is not inherently secure because it enables direct interrogation of the smart card and the recording of interactions with the smart card including their timing, so allowing cryptographic attack on the smart card.
  • such arrangements may be suitable in applications where the information supplied is not encrypted at all and the smart token is used only to certify the received information or where the carried information is encrypted but its value is very low or transient so that cryptographic attack on the smart card to allow decryption of the received information would not be cost effective.
  • the user access device will normally include a smart interface device which prevents cryptographic attack on a smart card itself.
  • the information transfer method of the invention is a two-way process able to support information flowing in both directions. Accordingly, it should be understood in the above description that, in general, references to the cryptographic encoder, encryption engine and smart tag should be understood as including the ability to both encrypt and decrypt information as required to support a bidirectional secure information flow. Of course, in practice any specific service or the hardware used to provide or access the service may only support information flow in a single direction for some or all parts of the service.

Abstract

Procédé de communication entre un premier et un deuxième dispositifs de chiffrage selon lequel un mécanisme de répartition pour chacun des trois éléments d'un flux de communications dans chaque direction est stocké par le premier dispositif de chiffrage. Les trois éléments du flux de communication sont un élément de commande d'accès, un élément de contenu d'informations et un élément de vérification. Chaque mécanisme de répartition définit les paramètres suivants: moyens de répartition; largeur de bande minimale demandée; largeur de bande maximale autorisée; latence maximale autorisée; force de cryptographie minimale; algorithmes cryptographiques acceptables; parent hiérarchique; et spécification source/destination. Pendant le fonctionnement, les premier et deuxième dispositifs de chiffrage négocient pour établir un ensemble de paramètres qui peuvent être pris en charge entre les dispositifs et sont conformes au mécanisme de répartition stocké par le premier dispositif.
PCT/GB2001/002680 2000-06-19 2001-06-18 Negociation entre dispositifs de chiffrage destinee a etablir des parametre pour la communication WO2001099380A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001274243A AU2001274243A1 (en) 2000-06-19 2001-06-18 Negotiation between encryption devices to establish parameters for communication

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0014980.7 2000-06-19
GB0014980A GB2363948A (en) 2000-06-19 2000-06-19 Communication method involving prior negotiation of parameters

Publications (1)

Publication Number Publication Date
WO2001099380A1 true WO2001099380A1 (fr) 2001-12-27

Family

ID=9893967

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2001/002680 WO2001099380A1 (fr) 2000-06-19 2001-06-18 Negociation entre dispositifs de chiffrage destinee a etablir des parametre pour la communication

Country Status (3)

Country Link
AU (1) AU2001274243A1 (fr)
GB (1) GB2363948A (fr)
WO (1) WO2001099380A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5719942A (en) * 1995-01-24 1998-02-17 International Business Machines Corp. System and method for establishing a communication channel over a heterogeneous network between a source node and a destination node

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5390252A (en) * 1992-12-28 1995-02-14 Nippon Telegraph And Telephone Corporation Authentication method and communication terminal and communication processing unit using the method
US6968379B2 (en) * 1997-05-30 2005-11-22 Sun Microsystems, Inc. Latency-reducing bandwidth-prioritization for network servers and clients
GB2337671B (en) * 1998-05-16 2003-12-24 Ibm Security mechanisms in a web server

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5719942A (en) * 1995-01-24 1998-02-17 International Business Machines Corp. System and method for establishing a communication channel over a heterogeneous network between a source node and a destination node

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
FREIER A O ET AL: "THE SSL PROTOCOL VERSION 3.0", INTERNET DRAFT, XX, XX, 18 November 1996 (1996-11-18), pages ABSTRACTS,1 - 72, XP002923866 *

Also Published As

Publication number Publication date
AU2001274243A1 (en) 2002-01-02
GB2363948A (en) 2002-01-09
GB0014980D0 (en) 2000-08-09

Similar Documents

Publication Publication Date Title
US7200230B2 (en) System and method for controlling and enforcing access rights to encrypted media
EP1574080B1 (fr) Procede et systeme permettant de fournir une authentification d'autorisation de tierce partie
US7231663B2 (en) System and method for providing key management protocol with client verification of authorization
US8694783B2 (en) Lightweight secure authentication channel
US20100017599A1 (en) Secure digital content management using mutating identifiers
US20200320178A1 (en) Digital rights management authorization token pairing
KR20040037155A (ko) 사용자 인증을 허용하는 사용자 단말의 고유 온라인프라비젼
KR20040053321A (ko) 보안 인터넷 프로토콜 권한 관리 아키텍쳐에 대한 키 관리프로토콜 및 인증 시스템
US11838409B2 (en) Method and apparatus for transferring data in a publish-subscribe system
US11936689B2 (en) Transmission of data or messages on board a vehicle using a SOME/IP communication protocol
Friesen et al. A comparative evaluation of security mechanisms in DDS, TLS and DTLS
US8699710B2 (en) Controlled security domains
WO2001099380A1 (fr) Negociation entre dispositifs de chiffrage destinee a etablir des parametre pour la communication
EP3406051B1 (fr) Procédé pour générer l'association de deux touches de terminal associées à l'aide d'un terminal et d'une passerelle, procédé de sécurisation d'échange de dates utilisant le procédé, un terminal et une passerelle
IL152435A (en) Secure digital content delivery system and method over a broadcast network

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP