WO2007043014A1 - Procede de communication chiffree mettant en oeuvre un flot de cles - Google Patents

Procede de communication chiffree mettant en oeuvre un flot de cles Download PDF

Info

Publication number
WO2007043014A1
WO2007043014A1 PCT/IB2006/053729 IB2006053729W WO2007043014A1 WO 2007043014 A1 WO2007043014 A1 WO 2007043014A1 IB 2006053729 W IB2006053729 W IB 2006053729W WO 2007043014 A1 WO2007043014 A1 WO 2007043014A1
Authority
WO
WIPO (PCT)
Prior art keywords
sequence
sink
source device
source
key
Prior art date
Application number
PCT/IB2006/053729
Other languages
English (en)
Inventor
Marc Vauclair
Original Assignee
Koninklijke Philips Electronics N.V.
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 Koninklijke Philips Electronics N.V. filed Critical Koninklijke Philips Electronics N.V.
Publication of WO2007043014A1 publication Critical patent/WO2007043014A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/065—Encryption by serially and continuously modifying data stream elements, e.g. stream cipher systems, RC4, SEAL or A5/3
    • H04L9/0656—Pseudorandom key sequence combined element-for-element with data sequence, e.g. one-time-pad [OTP] or Vernam's cipher
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12—Details relating to cryptographic hardware or logic circuitry

Definitions

  • the protocol between device i and devicey is as follows.
  • Device i generates a random sequence of bits denoted by r. This sequence r is sent to devicey together with a certificate for the public key of device i, which is denoted as cert(i).
  • Next devicey returns a message a which contains E 1 (K, ID j ), sig/a, r, IDJ and the certificate for the public key of devicey, which is denoted as cert(j).
  • the sequence K is generated randomly by devicey. This sequence K can be used in subsequent communication between the devices i and/ For instance K can be used as the initialization vector (IV) of a key generation algorithm.
  • ID 1 represents the identify of device i.
  • This protocol has as a disadvantage that the strength of the encryption protecting the content comes only from the randomly chosen sequence K of the second step of the protocol. In other words, for the strength of this key the protocol relies entirely on the contribution of one of the parties. There is a dissymmetry in the trust relationship. If the quality of the entropy o ⁇ K is low, then the entropy of the subsequently generated sessions keys will also be low.
  • the invention is characterized in that the method further comprises the step of using the first sequence r as part of an initialization vector of the encryption algorithm used for key stream generation.
  • a preferred embodiment uses AES- 128 in CTR mode as the encryption algorithm.
  • the invention can be used whenever a secure authenticated protocol is to be implemented with very strict efficiency constraints and that not all the nonces used for the mutual authentication contribute to the session key establishment. In other words, it can be used to optimize the use of the nonce in a secure authenticated channel by reusing some of them in the bulk encryption algorithm used to protect the confidentiality of the secure authenticated channel.
  • Fig. 1 schematically shows a system comprising devices interconnected via a network
  • Fig. 2 schematically illustrates a source device and a sink device
  • Fig. 3 schematically illustrates a key establishment protocol
  • Fig. 4 schematically illustrates generation and updating of a session key
  • Fig. 5 schematically illustrates the CTR mode of the AES- 128 algorithm
  • Fig. 6 schematically illustrates the SNOW 2.0 algorithm
  • Fig. 7 schematically illustrates how the AES- 128 block of Fig. 5 is used to generate 640 bits instead of 128 bits in one invocation;
  • Fig. 8 schematically shows an example configuration for the case where one AES- 128 block is used
  • Fig. 9 schematically shows an example configuration for the case where two AES-128 blocks are used in two lanes.
  • Fig. 10 schematically shows an example configuration for the case where two AES-128 blocks are used in four lanes.
  • Fig. 1 schematically shows a system 100 comprising devices 101-105 interconnected via a network 110.
  • a typical digital home network includes a number of devices, e.g. a radio receiver, a tuner/decoder, a CD player, a pair of speakers, a television, a VCR, a digital recorder, a mobile phone, a tape deck, a personal computer, a personal digital assistant, a portable display unit, a car entertainment system, and so on.
  • These devices are usually interconnected to allow one device, e.g. the television, to control another, e.g. the VCR.
  • One device such as e.g. the tuner/decoder or a set top box (STB), is usually the central device, providing central control over the others.
  • STB set top box
  • Content which typically comprises things like music, songs, movies, animations, speeches, videoclips for music, TV programs, pictures, games, ringtones, spoken books and the like, but which also may include interactive services, is received through a residential gateway or set top box 101.
  • Content could also enter the home via other sources, such as storage media like discs or using portable devices.
  • the source could be a connection to a broadband cable network, an Internet connection, a satellite downlink and so on.
  • the content can then be transferred over the network 110 to a sink for rendering.
  • a sink can be, for instance, the television display 102, the portable display device 103, the mobile phone 104 and/or the audio playback device 105.
  • the exact way in which a content item is rendered depends on the type of device and the type of content.
  • rendering comprises generating audio signals and feeding them to loudspeakers.
  • rendering generally comprises generating audio and video signals and feeding those to a display screen and loudspeakers.
  • Rendering may also include operations such as decrypting or descrambling a received signal, synchronizing audio and video signals and so on.
  • the set top box 101 may comprise a storage medium Sl such as a suitably large hard disk, allowing the recording and later playback of received content.
  • the storage medium Sl could be a Personal Digital Recorder (PDR) of some kind, for example a DVD+RW recorder, to which the set top box 101 is connected.
  • Content can also enter the system 100 stored on a carrier 120 such as a Compact Disc (CD) or Digital Versatile Disc (DVD).
  • CD Compact Disc
  • DVD Digital Versatile Disc
  • the portable display device 103 and the mobile phone 104 are connected wirelessly to the network 110 using a base station 111, for example using Bluetooth or IEEE 802.1 Ib.
  • the other devices are connected using a conventional wired connection.
  • several interoperability standards are available, which allow different devices to exchange messages and information and to control each other.
  • One well- known standard is the Universal Plug and Play (http://www.upnp.org) standard. It is important to ensure that the devices 101-105 in the home network do not allow the creation of unauthorized copies of the content.
  • the devices 101-105 are provided with a data protection system for a digital display interface. This data protection system ensures that only authorized and protected content transfers can occur from a first device, hereafter referred to as source device or just source, to a second device, hereafter referred to as sink device or just sink.
  • Fig. 2 schematically illustrates a source device 200 and sink device 220. Both devices comprise a digital interface IF, a processor CPU and a storage component MEM.
  • the source device 200 is a device that holds content which is to be streamed (or otherwise transmitted) to the sink device 220.
  • the sink device 220 then typically is a device that receives this streamed content and renders it, e.g. on a display screen.
  • any of the devices 101-105 mentioned above may operate as the source device 200 and/or as the sink device 220. It is worth noting that a device may operate as source device relative to one other device, and as sink device relative to a further device. This may even occur simultaneously.
  • Source and Sink is a digital video recorder (DVR) connected to a digital television display.
  • DVR digital video recorder
  • the digital audiovisual content recorded by the DVR is streamed to the display so the user can watch the content.
  • the interface between source device 200 and sink device 220 comprises a high-speed unidirectional main link 211 and a relatively low-speed bidirectional auxiliary channel 212.
  • the main link 211 can carry up to 10 Gigabits per second and the auxiliary channel 212 has a 1 Megabit per second transfer rate.
  • the main link 211 is used to carry compressed or uncompressed digital data such as video and/or audio data spread over one or more lanes. Lanes are data paths between the source and the sink over by the secure authenticated channel. Data transported over a lane is bulk-encrypted. In some protocols, like for digital video transport, more than one lane is used, for example to improve the bandwidth of the link.
  • a secure authenticated channel In many cases, a SAC is set up using an Authentication and Key Exchange (AKE) protocol that is based on public key cryptography. In the present invention, a SAC 210 is set up as shown in Fig. 2 to protect the data transferred over the main link and auxiliary link.
  • AKE Authentication and Key Exchange
  • Public key cryptography and digital certificates may be used for mutual authentication between the source and sink devices.
  • the data is transferred over the main link in encrypted form.
  • the system should be resistant to the hacking of individual components, which might enable illegal storing, copying and/or redistribution of digital content.
  • An important technique to increase the resistance is the so-called revocation of these hacked devices. This requires all clients to read a so-called Certificate Revocation List (CRL), a list allowing identification of revoked clients. Clients are forced in some manner to possess an up-to-date CRL, and they should never pass content to clients that are identified as revoked by the CRL.
  • CRL Certificate Revocation List
  • a central authority generates and distributes new CRLs whenever necessary.
  • Revocation can be indicated in several different manners. Two different techniques are so-called black lists (a list of revoked devices) and white lists (a list of un- revoked devices).
  • black lists a list of revoked devices
  • white lists a list of un- revoked devices.
  • black lists a list of revoked devices
  • white lists a list of un- revoked devices.
  • black lists clients that have been revoked are listed, and a client thus is revoked if it appears on the black list.
  • the “white list” approach is the reverse. In this approach a client thus is revoked if it does not appear on the white list.
  • “being revoked” or “being on the revocation list” means “appearing on the black list” or “not appearing on the white list” depending on which approach is used.
  • Clients are identified on the blacklist or the white list by a unique identifier, such as a serial number.
  • a client may have a unique identifier installed in the factory. This globally unique identifier can then be listed in the CRL.
  • a residential gateway or domain manager device may assign unique identifiers to devices as they join the local network or domain. These identifiers can be used in a CRL to be used in the local network domain (sometimes called a "local CRL") instead of globally unique identifiers.
  • the residential gateway or domain manager may to this end convert a CRL received from the central authority into a local CRL by mapping the globally unique identifiers onto the assigned identifiers.
  • Revocation data may be distributed in a variety of ways.
  • the CA could transmit the list to the clients as a signal via a network, for example on request from these clients.
  • the list could also be transmitted periodically.
  • a device that receives the list from the CA could transmit the list to other devices to which it is connected.
  • the present invention focuses on the key establishment protocol during the process of setting up the SAC and the bulk encryption of the data sent from the source device ("Source”) to the sink device (“Sink”).
  • the protocol is illustrated in Fig. 3. Each phase of the protocol is now described in turn.
  • KPub src denotes the public key of a public/private key pair held by device 'src'.
  • KPriv src denotes the private key of a public/private key pair held by device 'src'.
  • Cert src denotes a certificate issued for a device 'src'. Where the validity of a certificate needs to be established, the public key of a certifying authority (CA) is used. This key is denoted as KPub root .
  • ID src denotes a unique identifier of device 'src'.
  • CPI Content Protection Information
  • the Source holds KPub src , KPrivsrc, ID src , cert src and KPub root .
  • the Sink holds KPub sn k, KPriv sn k, ID snk , cert snk , and KPubroot.
  • the protocol begins when the Source sends out a "Connection request" message (ConReqMsg) to the sink.
  • ConReqMsg The purpose of the "Connection request" message is to trigger the Sink to send the first message of the authentication protocol to the Source.
  • the Sink may initiate the authentication protocol without receiving a "ConReqMsg" from the Source first. For instance, the Sink may detect that a network cable or connector is connected to one of its interfaces, and use this event as a trigger to initiate the authentication protocol. The user of the Sink may also manually initiate the authentication protocol.
  • the authentication protocol is designed to achieve mutual authentication. First the Sink sends an "AuthSnkMes" and the Source responds with an "AuthSrcMes". The authentication phase establishes the security and a certain level of trust of the link. Additional trust of the link may be obtained by using device revocation and the device counting and proximity detection methods described below.
  • the Sink chooses a sequence r of random bits.
  • the length of the sequence depends on the cryptographic algorithm that is used later on.
  • the sequence r is preferably 64 bits long (i.e. 64 bits for the nonce and 64 bits for the counter that are concatenated to form a 128 bits string as input to the AES- 128).
  • This sequence r is the nonce of the SAC establishment protocol.
  • This sequence r is sent to the Source together with cert sn k in the AuthSnkMes. Next, the Source extracts ID src from cert src and verifies if this ID src is on a
  • Certificate Revocation List The Source verifies the signature on cert sn k, using KPub root . If the signature is authentic, the Source extracts ID sn k and KPub sn k from cert sn k and verifies if ID sn k is on a Certificate Revocation List. If either ID is revoked, the protocol is aborted.
  • the Source chooses a random sequence K, preferably 256 bits long.
  • the sequence K together with ID src , is encrypted using the public key of the Sink KPub sn k to produce the message a.
  • other information e.g. the Content Protection Information (CPI) and an identifier of the encryption protocol to be used later on is encrypted as well.
  • the information to be encrypted is preferably concatenated into one bit sequence first.
  • the message a together with the random sequence r and ID sn k is signed using KPrivsrc into sig ⁇ .
  • the Source then sends the message a, the signature sig ⁇ and cert src to the Sink in the message "AuthSrcMes".
  • the Sink receives the AuthSrcMes and verifies the signature on cert src , using KPubroot.
  • the Sink also verifies the signature sig ⁇ using KPub roo t. If one or both of the signatures cannot be verified, the Sink aborts the protocol. If the signatures are valid, the Sink decrypts the message a using KPriv sn k.
  • the Sink next extracts the ID src that is present in the cert src and compares this against the ID src that was present in the encrypted message a. This provides confirmation of the identity of the Source.
  • the Sink also processes any other information that may have been included in the encrypted message a. Now both the Sink and the Source know the values KPub src , KPub sn k, r, K,
  • KPubroot, certsrc, certsnk, IDsrc, IDsnk and the optional other information that was included in the encrypted message a This means the secure authenticated channel has been set up.
  • the channel can be used for encrypted data transfers.
  • Data messages "DataMes" can now be sent from Source to Sink. Both Source and Sink must next engage in the computation of a session key that will be used to encrypt and decrypt the data to be transferred.
  • New session keys may be computed at regular intervals during the data transfer. Different session keys can be computed for encryption purposes, for authentication purposes and for the proximity detection described below.
  • the session key for encryption purposes is referred to as SE.
  • Session keys are computed using a cryptographic hash function, preferably the SHA-256 algorithm, which is described in the NIST publication "Descriptions of SHA-256, SHA-384, and SHA-512" available on the Internet at ⁇ http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf>
  • the data is encrypted using the session key SE.
  • the session key should be changed regularly. This may be realized by having both the Source and Sink keep track of a counter, called cipherBlockCnt. Both Source and Sink increase this counter every time they send and receive a block, respectively. When this counter cipherBlockCnt reaches a predetermined level, the Source initiates an update of the session key SE. A message to this effect is then sent over the auxiliary link 212 to the Sink.
  • the generation and updating of the session key SE is illustrated in Fig. 4. Note that the numbers in Figs. 4 and further represent bit lengths of the inputs and outputs in question.
  • the random sequence K chosen earlier by the Source and the SessionKeyUpdCtr counter are concatenated and used as input to the cryptographic hash function. If necessary the input should be padded, e.g. with zeroes or ones, to obtain an input string of the required length.
  • SHA-256 for example requires 512 bits of input to produce a hash that is 256 bits long.
  • a fixed string can also be provided as an input to the cryptographic hash function. In Fig. 4 the fixed string "DPCP-E" is used.
  • SessionKeyUpdCtr is a counter of session key updates. SessionKeyUpdCtr is 0 at the beginning of the session and monotonically increases with time. SessionKeyUpdClk provides a signal to indicate that the session key should be updated.
  • the data messages are encrypted using a combination of the AES- 128 algorithm running in Counter Mode (CTR mode) with the SNOW 2.0 algorithm.
  • AES Advanced Encryption Standard
  • AES has a fixed block size of 128 bits and a key size of 128, 192 or 256 bits, whereas Rijndael can be specified with key and block sizes in any multiple of 32 bits, with a minimum of 128 bits and a maximum of 256 bits.
  • the specification of the AES algorithm is published as US Federal Information Processing Standards Publication 197.
  • Rijndael is discussed in J. Daemen and V. Rijmen, Rijndael, the advanced encryption standard, Dr. Dobb's Journal, Vol. 26, No. 3, March 2001, pp. 137-139.
  • the CTR mode of the AES- 128 algorithm is illustrated in Fig. 5.
  • the reader is referred to Morris Dworkin, Recommendation for Block Cipher Modes of Operation, NIST Special Publication 800-38 A 2001 Edition, available on the Internet at ⁇ http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf>.
  • the SNOW 2.0 algorithm is disclosed in P. Ekdahl, T. Johansson, "A new version of the stream cipher SNOW" (version 2.0 - SAC 2002), available on the Internet at ⁇ http://www.it.lth.se/cryptology/snow/snow20.pdf>.
  • AES- 128 is used to generate a key stream. This stream is subsequently used to update the internal state of the SNOW 2.0 algorithm with pseudo-random values.
  • the SNOW 2.0 algorithm is used to encrypt the content by generating a key stream that is XOR'ed with the content.
  • the content is presented in blocks to the SNOW algorithm, e.g. 32 bits in size.
  • the AES- 128 algorithm is known to be strong. However, a disadvantage of AES is that it can be too slow for processing high-bandwidth data, such as the envisaged 10 gigabits per second data transfer occurring on the main link 211. This is especially true for low cost devices.
  • the SNOW 2.0 algorithm is fast enough to handle content that is presented at such high speed. However, this algorithm is relatively new and hence its security level is uncertain. By combining these two algorithms in this manner, the security of the system as a whole is improved.
  • the random sequence (nonce) r chosen above during the establishment of the SAC is now also used as the nonce for the AES- 128 algorithm used in CTR mode. As noted in section B.2 of the above-referenced NIST recommendation, the uniqueness of the nonces should be ensured. This is achieved according to the invention by re-using the random sequence r.
  • P represents the counter block output, i.e. the AES- 128 data input.
  • SE is used as the AES secret key.
  • C represents the output key stream.
  • W represents a string needed for initialization of the SNOW 2.0 algorithm.
  • the ctr registers of the AES- 128 block(s) are set to 0 and the AES-128 block(s) is (are) clocked 5 times to deliver 640 bits out of which the first 576 bits are retained to form the first JFstring(s) needed for initializing the SNOW 2.0 block(s). This operation is illustrated in Fig. 7.
  • SNOW 2.0 is a stream cipher algorithm that operates on blocks of 32 bits at a time.
  • the internal state of this algorithm comprises a Linear Feedback Shift Register (LFSR) of 512 bits and two registers Rl and R2, each 32 bits long. At regular intervals the internal state of the algorithm is loaded with pseudo-random data which is computed by the AES block.
  • the state variables (LFSR + Rl + R2) concatenated give the value W.
  • DataBlockClk provides a signal for every 32 bits of data on the input. This is followed by one SNOW2.0 execution to deliver 32 bits of encrypted data.
  • DataBlockCtr is a counter that counts the number of encrypted blocks. DataBlockCtr is initialized at 0 at the beginning of the session and monotonically increases during the session.
  • a new session key SE is computed and the next 576 bits for W are produced using the current value of SE by clocking the AES- 128 block(s) 5 times.
  • Fig. 7 illustrates how the AES- 128 block of Fig. 5 is used to generate 640 bits instead of 128 bits in one invocation. Those new W bits will be used at the next key update.
  • the AES- 128 block(s) are running in parallel with the SNOW 2.0 block(s). This implies that the AES-128 block(s) can take as much time as the interval between two session key updates.
  • the devices may employ one AES-128 block or two or four AES-128 blocks that run in parallel.
  • Example implementations are shown in Figs. 8-10.
  • a configuration for the case where one AES-128 block is used is shown in more detail in Fig. 8.
  • a two-lane configuration is shown in more detail in Fig. 9.
  • a four- lane configuration is shown in more detail in Fig. 10. In those Figs, the symbol
  • a clock signal multiplier i.e. the output clock runs at 5 times the input clock in the given example
  • the symbol denotes a clock signal divider (i.e. the output clock runs 16 times slower than the input clock in the given example).
  • Another step shown in Fig. 3 is proximity detection. This step is used to determine whether a Source and Sink are sufficiently close. This can be done in a variety of ways. Basically the Source sends a proximity detection request message "ProxCtrlReqMes" and the Sink responds with a proximity detection response message "ProxCtrlRepMes". The time between sending the request and receiving the response is used to determine whether Source and Sink are sufficiently close. Another optional extra step is display counting. In this step, the Source verifies whether it is connected to more than a certain number of Sink devices. If so, it aborts the connection with the Sink. A Sink may operate as Source to yet further Sink devices.
  • These further Sink devices may be reported to the Source, so that the Source knows it is not only connected to one Sink but actually to multiple Sinks. At regular intervals during data transfer the proximity detection and/or display count steps may be repeated to verify whether Source and Sink are still in the required proximity of each other, and whether no extra display devices have been added in the meantime.
  • the private keys denoted as Kp ⁇ v , should be protected against tampering or unauthorized copying. Preferably they are stored in a tamper resistant place, e.g. using secure hardware.
  • the invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer.
  • the device claim enumerating several means several of these means can be embodied by one and the same item of hardware.
  • the mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé permettant d'établir une connexion sécurisée entre un dispositif source et un dispositif récepteur, aux fins de transfert de données. Le procédé comprend les étapes suivantes : au niveau d'un des dispositifs, une première séquence r choisie de manière pseudo-aléatoire est envoyée à l'autre dispositif. Celui-ci retourne une seconde séquence K choisie de manière pseudo-aléatoire et une signature numérique pour au moins la première séquence r. La seconde séquence K est utilisée pour établir une clé de session permettant de chiffrer et de déchiffrer les données à transférer du dispositif source au dispositif récepteur. La première séquence r est utilisée comme une partie d'un vecteur d'initialisation d'un algorithme de chiffrement utilisé pour la génération de flot de clés.
PCT/IB2006/053729 2005-10-13 2006-10-11 Procede de communication chiffree mettant en oeuvre un flot de cles WO2007043014A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP05109527 2005-10-13
EP05109527.1 2005-10-13

Publications (1)

Publication Number Publication Date
WO2007043014A1 true WO2007043014A1 (fr) 2007-04-19

Family

ID=37685956

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2006/053729 WO2007043014A1 (fr) 2005-10-13 2006-10-11 Procede de communication chiffree mettant en oeuvre un flot de cles

Country Status (1)

Country Link
WO (1) WO2007043014A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2965431A1 (fr) * 2010-09-28 2012-03-30 Mouchi Haddad Systeme d'echange de donnees entre au moins un emetteur et un recepteur
WO2022173930A1 (fr) * 2021-02-12 2022-08-18 Visa International Service Association Échange de données d'identité préservant la confidentialité basé sur un chiffrement hybride
US20220369113A1 (en) * 2021-05-05 2022-11-17 Texas Instruments Incorporated Methods and apparatus to synchronize devices

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1063811A1 (fr) * 1999-06-22 2000-12-27 Hitachi Europe Limited Appareil et procédé cryptographique
WO2001017251A1 (fr) * 1999-08-29 2001-03-08 Intel Corporation Procede et dispositif de chiffrement et de dechiffrement de la transmission d'un contenu video numerique

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1063811A1 (fr) * 1999-06-22 2000-12-27 Hitachi Europe Limited Appareil et procédé cryptographique
WO2001017251A1 (fr) * 1999-08-29 2001-03-08 Intel Corporation Procede et dispositif de chiffrement et de dechiffrement de la transmission d'un contenu video numerique

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
MITSUYAMA Y ET AL: "VLSI implementation of high performance burst mode for 128-bit block ciphers", ASIC/SOC CONFERENCE, 2001. PROCEEDINGS. 14TH ANNUAL IEEE INTERNATIONAL SEPT. 12-15, 2001, PISCATAWAY, NJ, USA,IEEE, 12 September 2001 (2001-09-12), pages 3 - 7, XP010560746, ISBN: 0-7803-6741-3 *
STEINER M ET AL: "REFINEMENT AND EXTENSION OF ENCRYPTED KEY EXCHANGE", 1 July 1995, OPERATING SYSTEMS REVIEW, ACM, NEW YORK, NY, US, PAGE(S) 22-30, ISSN: 0163-5980, XP000529095 *
V. SCHOUP: "On Formal Models for Secure Key Exchange (version 4)", IBM SEARCH REPORT, 15 November 1999 (1999-11-15), XP002418690 *
YA-PING ZHANG ET AL: "A stream cipher algorithm based on conventional encryption techniques", ELECTRICAL AND COMPUTER ENGINEERING, 2004. CANADIAN CONFERENCE ON NIAGARA FALLS, ONT., CANADA 2-5 MAY 2004, PISCATAWAY, NJ, USA,IEEE, US, 2 May 2004 (2004-05-02), pages 649 - 652Vol2, XP010733530, ISBN: 0-7803-8253-6 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2965431A1 (fr) * 2010-09-28 2012-03-30 Mouchi Haddad Systeme d'echange de donnees entre au moins un emetteur et un recepteur
WO2012042170A1 (fr) * 2010-09-28 2012-04-05 Mouchi Haddad Système d'échange de données entre au moins un émetteur et un récepteur
US8914640B2 (en) 2010-09-28 2014-12-16 Mouchi Haddad System for exchanging data between at least one sender and one receiver
WO2022173930A1 (fr) * 2021-02-12 2022-08-18 Visa International Service Association Échange de données d'identité préservant la confidentialité basé sur un chiffrement hybride
US11956359B2 (en) 2021-02-12 2024-04-09 Visa International Service Association Privacy preserving identity data exchange based on hybrid encryption
US20220369113A1 (en) * 2021-05-05 2022-11-17 Texas Instruments Incorporated Methods and apparatus to synchronize devices
US11863992B2 (en) * 2021-05-05 2024-01-02 Texas Instruments Incorporated Methods and apparatus to synchronize devices

Similar Documents

Publication Publication Date Title
KR100924106B1 (ko) 디지털 데이터를 소스로부터 수신기로 안전하게 송신하는방법
KR101366243B1 (ko) 인증을 통한 데이터 전송 방법 및 그 장치
US7242766B1 (en) Method and system for encrypting and decrypting data using an external agent
US6542610B2 (en) Content protection for digital transmission systems
US7184550B2 (en) Method and apparatus for simultaneous decryption and re-encryption of publicly distributed content via stream ciphers
US9247024B2 (en) Controlled activation of function
US8468350B2 (en) Content transmission apparatus, content reception apparatus and content transmission method
EP1271875A1 (fr) Dispositif pour l'échange de données, et procédé de fabrication
US20060155991A1 (en) Authentication method, encryption method, decryption method, cryptographic system and recording medium
US20080267399A1 (en) Method and Apparatus for Secure Content Recording
JPH118620A (ja) 通信チャネルの認証を効率的に実施し、不正な変更の検出を容易にするシステムおよび方法
US20080046731A1 (en) Content protection system
KR20060020688A (ko) 개선된 안전 인증 채널
KR20040108533A (ko) 콘텐츠 송신 장치, 콘텐츠 수신 장치 및 콘텐츠 전송 방법
JP4193380B2 (ja) ストリーム転送における電子署名システム
US6516414B1 (en) Secure communication over a link
JP2005503717A (ja) Ｕｓｂ認証インタフェース
US7886160B2 (en) Information processing apparatus and method, and computer program
JPH118618A (ja) 機器認証方法及び装置並びに認証システム
WO2007043014A1 (fr) Procede de communication chiffree mettant en oeuvre un flot de cles
WO2007043002A2 (fr) Systeme de securite ameliore
WO2007043015A2 (fr) Procede de detection de proximite ameliore
US8312166B2 (en) Proximity detection method
US20110185182A1 (en) Improvements related to the authentication of messages
CN113965361B (zh) 一种用于服务器间的通信方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06809566

Country of ref document: EP

Kind code of ref document: A1