WO2007043014A1

WO2007043014A1 - Method of encrypted communication using a keystream

Info

Publication number: WO2007043014A1
Application number: PCT/IB2006/053729
Authority: WO
Inventors: Marc Vauclair
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2005-10-13
Filing date: 2006-10-11
Publication date: 2007-04-19

Abstract

The invention relates to a method of establishing a secure connection between a source device and a sink device for the transfer of data. The method comprises the following steps. At one of the devices a first (pseudo-)randomly chosen sequence r is sent to the other one of the devices. The other device returns a second (pseudo-)randomly chosen sequence K and a digital signature for at least the first sequence r. The second sequence K is used to establish a session key for encrypting and decrypting the data to be transferred from the source device to the sink device. The first sequence r is used as part of an initialization vector of an encryption algorithm used for key stream generation.

Description

Improved method of communication

The document "On formal models for secure key exchange" (version 4), November 15, 1999 revision of IBM Research Report RZ 3120 (April 1999) by Victor Shoup discloses an encryption-based key exchange (EKE) protocol in section 8.1. In this protocol, each device has two public/private key pairs: one for a digital signature scheme, and one for a public key encryption scheme. This document is available on the Internet at <http://shoup.net/papers/skey.pdf>.

Let sig/msg) denote that the message msg has been signed by device i. Let E₁(MSg) denote that the message msg has been encrypted using the public key for device i.

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₁(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₁ 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.

It is an object of the invention to improve the strength of the encryption protecting the content.

This object is achieved in that 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. By using the random sequence r as a second source of randomness, the quality of the encrypted output is improved and the protocol is made more symmetric. Now both parties contribute randomness to the protocol, which increases its security and the trust relationship. Moreover, for many cryptographic algorithms a random choice of initialization vector (IV) is better than a fixed choice. Using the random value r as random IV thus improves the quality of the cryptographic output.

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.

Advantageous embodiments are set out in the dependent claims.

The invention will now be discussed in more detail with reference to the figures, in which:

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; and

Fig. 10 schematically shows an example configuration for the case where two AES-128 blocks are used in four lanes.

Throughout the figures, same reference numerals indicate similar or corresponding features. Some of the features indicated in the drawings are typically implemented in software, and as such represent software entities, such as software modules or objects.

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.

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. For instance, in a radio receiver, rendering comprises generating audio signals and feeding them to loudspeakers. For a television receiver, rendering generally comprises generating audio and video signals and feeding those to a display screen and loudspeakers. For other types of content a similar appropriate action must be taken. 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, or any other device in the system 100, 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).

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. To allow the devices 101-105 to interact, 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. Hence 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.

Typically 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.

An example of Source and Sink is a digital video recorder (DVR) connected to a digital television display. The digital audiovisual content recorded by the DVR is streamed to the display so the user can watch the content.

As shown in Fig. 2, 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. In an embodiment envisaged by the inventors, 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. Technology to perform device authentication and encrypted content transfer is available and is called a secure authenticated channel (SAC). 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.

SACs and the underlying technologies are well known. 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. 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). In the "black list" approach, 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. In this document, "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. Alternatively 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.

In this protocol description, 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'.

Content Protection Information (CPI) may be provided from the application that triggers the activation of the protocol.

If any error occurs during the processing of the various protocol phases (timeout, erroneous answer, unrecoverable errors...), the protocol is aborted and the Source should not transmit the content to the sink.

At the beginning of the authentication protocol, the Source holds KPub_src, KPrivsrc, ID_src, cert_src and KPub_root. Similarly, the Sink holds KPub_snk, KPriv_snk, ID_snk, cert_snk, and KPubroot. The protocol begins when the Source sends out a "Connection request" message (ConReqMsg) to the sink. The purpose of the "Connection request" message is to trigger the Sink to send the first message of the authentication protocol to the Source.

As an alternative 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. In case AES- 128 is used in CTR mode, 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_snk 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_snk, using KPub_root. If the signature is authentic, the Source extracts ID_snk and KPub_snk from cert_snk and verifies if ID_snk is on a Certificate Revocation List. If either ID is revoked, the protocol is aborted.

Next, 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_snk to produce the message a. Optionally 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_snk 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_root. 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_snk.

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_snk, 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. For additional security 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. To compute the session key SE, 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. Optionally 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.

In the preferred embodiment, 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) is a standardized version of the Rijndael algorithm. 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. For more information 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. On the other hand, 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. For more information, the reader is referred to US patent application serial number 60/651303 (attorney docket PHUS050068) which describes a method to combine a strong block cipher in counter mode with a stream cipher that uses the output of this block cipher to update its internal state.

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.

The following notation is used. 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.

First the AES- 128 algorithm must be initialized. 64 bits of the random sequence r that was used earlier are now used together with a counter register ctr as input to the AES- 128 algorithm.

When the first session key SE is generated, 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.

The SNOW 2.0 cryptographic algorithm is illustrated in Fig. 6. 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.

Note that during this first initialization, the SNOW 2.0 block(s) are not used and no content is encrypted.

After this first initialization and whenever a key update occurs 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. This means that 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.

Whenever a new session string W of 576 bits is generated, those 576 bits (512+32+32) are used to re-initialize the internal state of the SNOW 2.0 block(s). At initialization time or whenever a key update is requested, the SNOW 2.0 internal state is initialized with the currently available W by putting the first 512 bits in the LFSR, the next 32 bits in Rl and the last 32 bits in R2.

After initialization of the internal state of SNOW 2.0, the algorithm is used in the usual manner as described in the SNOW article cited above. 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

denotes a clock signal multiplier (i.e. the output clock runs at 5 times the input clock in the given example) and 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.

This process requires the use of public/private key pairs. 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.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements.

The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In 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.

Claims

CLAIMS:

1. A method of establishing a secure connection between a source device and a sink device for the transfer of data, comprising the steps of at one of the devices, sending a first (pseudo-)randomly chosen sequence r to the other one of the devices, at the other device, returning a second (pseudo-)randomly chosen sequence K and a digital signature for at least the first sequence r, and using the second sequence K to establish a session key for encrypting and decrypting the data to be transferred from the source device to the sink device, characterized in that the method further comprises the step of using the first sequence r as part of an initialization vector of an encryption algorithm used for key stream generation.

2. The method of claim 1, wherein the sink device sends the first sequence r to the source device and the source device returns the second sequence K.

3. The method of claim 1 , wherein the second sequence K is used as an input to a cryptographic hash function whose output is used as the session key.

4. The method of claim 1, wherein the encryption algorithm is AES-128 in CTR mode.

5. A source device comprising communication means (IF) for receiving a first (pseudo-)randomly chosen sequence r from a sink device, comprising cryptographic means (CPU) for computing a digital signature for at least the first sequence r, communication means (IF) for returning a second (pseudo-)randomly chosen sequence K and the digital signature for at least the first sequence r to the sink device, cryptographic means (CPU) for using the second sequence K to establish a session key for encrypting and decrypting the data to be transferred from the source device to the sink device, characterized in that the cryptographic means (CPU) are further configured for using the first sequence r as part of an initialization vector of the encryption algorithm used for key stream generation.

6. A sink device comprising communication means (IF) for transmitting a first (pseudo-)randomly chosen sequence r to a source device and for receiving from the source device returning a second (pseudo-)randomly chosen sequence K and a digital signature for at least the first sequence r, cryptographic means (CPU) for verifying the digital signature and for, if the digital signature is verified successfully, using the second sequence K to establish a session key for encrypting and decrypting the data to be transferred from the source device to the sink device, characterized in that the cryptographic means (CPU) are further configured for using the first sequence r as part of an initialization vector of the encryption algorithm used for key stream generation.