WO2009122165A1

WO2009122165A1 - Authentication of transmissions

Info

Publication number: WO2009122165A1
Application number: PCT/GB2009/000855
Authority: WO
Inventors: Afnan Ullah Khan; Theo Dimitrakos
Original assignee: British Telecommunications Public Limited Company
Priority date: 2008-03-31
Filing date: 2009-03-31
Publication date: 2009-10-08
Also published as: GB0805831D0

Abstract

A method of authenticating a second transmitted (e.g. broadcast) media item received by a recipient as having come from the same source as a first transmitted (e.g. broadcast) media item comprising the steps of: generating a first key, generating a first chain of one or more subsequent keys using one or more one way functions, the one or more subsequent keys being generatable from the first key by applying the one or more one way functions to the first key, storing the one or more subsequent keys in a memory, transmitting a first item with an element including, or derived using, a subsequent key, generating a second key not forming part of the first chain, sending a message calculated from the first key and the second key, transmitting a second item with an element including the second key, subsequent to transmitting the first item, sending the first key to the recipient, subsequent to sending the message, the first key allowing the recipient to check that the message was calculated from the second and first keys and that the subsequent key received with the first item can be generated from the first key by one or more applications of the one way function.

Description

Authentication of transmissions

This invention relates to a method of authentication, in particular but not exclusively a method of authentication of a video source in a scaleable video scenario.

It is becoming increasingly popular to distribute media such as video by unconventional means and in particular over the internet. This has led to problems with authentication of the media source. In particular it is known for third parties to try and hijack a video stream infrastructure by sending their own content over the infrastructure and passing it off as coming from the intended source. Further, instead of simply replacing the transmission it may be possible to edit or corrupt it. For example a third party could attempt to strip out adverts from a TV programme which has been paid for and insert their own commercials without paying the required fee.

In order to prevent this and other problems various methods have been proposed to authenticate that a transmission is coming from the original intended source.

If a standard message authentication code (MAC) is appended to each video packet using a shared symmetric key, any receiver of the shared key (such as a party who has paid to legitimately receive the transmission) can forge the MACs and inject video packets into the stream.

Asymmetric cryptographic protocols such as digital signatures can be used or transmissions can be made over authenticated channels such as EPSec (IP security) or TLS (Transport Layer Security). These can be effective for authentication but have a large overhead in terms of computational power, time and bandwidth. It has also been proposed, principally from a paper, by Adrian Perrig, Ran

CanettiJ. D. Tygar, and Dawn Song, named 'TESLA Broadcast authentication protocol' (which can be found at http ://www.ece. emu. edu/~adrian/proi ects/tesla- cryptobytes/paper/paper.htrnl ) to use a protocol which relies on one-way chains, symmetric MACs and a time source for authentication of broadcasts. The above mentioned TESLA (Time Efficient Stream Loss-tolerant

Authentication) broadcast authentication protocol is said to be an efficient protocol with low communication computation overhead which scales to a large number of receivers and tolerates packet loss. Additionally it relies on symmetric encryption and therefore does not need to use asymmetric cryptography and only requires a single MAC per packet.

Whilst the TESLA protocol has been found to be useful for some transmissions it does suffer the disadvantage that it can only be used to authenticate that information from a source using the TESLA protocol is from the same source as transmissions sent earlier by the same source using the same one-way TESLA chain.

Accordingly to authenticate that the first packet using a particular key chain is from the correct source, another method of authentication should be used, such as an asymmetric protocol such as digital signatures or the use of an authenticated channel. Key chains are generally of a finite length. As with all encryption techniques the more times that a key is used, or keys derived from the same key are used (as with a TESLA chain) the easier it is to break the encryption, and therefore a limited length of key chain is desirable. According it is desirable to change key chains every so often and the additional method with increased overhead should be used each time a new chain is used

It has also recently become known to distribute video with a system known as scalable video. In scalable video the video data bitstream is partitioned into layers - a base layer which is decodable independently of the other layer(s) into a video sequence with reduced spatial/temporal or SNR; and one or more enhancement layers which provide additional data necessary for video reproduction with higher spatial or temporal resolution or a higher signal-to-noise ratio. This allows a video source to transmit a video with a number of component parts allowing its resolution to be scaled up or scaled down depending on the needs of an end user. Typically scalability servers are provided between the video server and the end users, with end users of a particular requirement such as a low resolution being connected to the same scalability server and the scalability server taking the unsealed video from the video server and scaling it appropriately to its end users. In such systems there may be no direct contact between the source of a video transmission (e.g. the broadcaster) and the end user which causes additional problems for authentication. The TESLA protocol has been found to be particularly effective for use with a scalable video system, particularly with the modifications provided by the present invention as described below. It is an object of the current invention to at least mitigate some of the above mentioned problems.

According to the first aspect of the invention there is provided a method of authenticating a second broadcast (data) item received by a recipient as having come from the same source as a first broadcast (data) item comprising the steps of: generating a first key, generating a first chain of one or more subsequent keys using one or more one way functions, the one or more subsequent keys being generatable from the first key by applying the one or more one way functions to the first key, storing the one or more subsequent keys in a memory, broadcasting a first (data) item with an element including, or derived using, a subsequent key, generating a second key not forming part of the first chain, sending a message calculated from the first key and the second key, broadcasting a second (data) item with an element including the second key, subsequent to broadcasting the first item, sending the first key to the recipient, subsequent to sending the message, the first key allowing the recipient to check that the message was calculated from the second and first keys and that the subsequent key received with the first (data) item can be generated from the first key by one or more applications of the one way function.

According to a second aspect of the invention there is provided a broadcast server for broadcasting at least two items to a recipient which are authenticable as coming from the same source, the server comprising a processor and a memory, the server having a first key stored in the memory or the server is configured to generate a first key, the server having a first chain of one or more subsequent keys generatable using one or more one way functions stored in the memory, the one or more subsequent keys being generatable from the first key by applying the one or more one way functions to the first key, the server configured to broadcast a first item with an element including, or derived using, a subsequent key, to send a message calculated from the first key and a second key not forming part of the first chain which second key is stored in the memory and/or generated by the server, to broadcast a second item with an element including the second key, subsequent to broadcasting the first item, to send the first key to a recipient, subsequent to sending the message.

According to a third aspect of the invention there is provided an authenticating receiver, preferably a video packet receiver, such as a set top box, for receiving broadcasts of items and authenticating that a received item is from the expected source, the receiver comprising a memory, the memory including a one way function and a subsequent key generatable from a first key using the one way function, the receiver configured on receipt of an identifiable type of message, a broadcast item with an element including, or derivable from, a second key not generatable form the first key by use of the one way function, subsequent to broadcasting the first item, and the first key checking that the message was calculated from the second and first keys and that the subsequent key in the memory can be generated from the first key by one or more applications of the one way function.

Further preferred or optional features of the invention are set out in the claims.

Embodiments of the invention find particular application in on-demand video distribution systems, but also find application in both broadcast and multicast distribution systems. While described in the context of video distribution, embodiments of the invention can also be applied to the distribution of other media and not just video.

Embodiments of invention are particularly suited to video on demand applications such as the product offered in the UK under the brand name BT Vision. Other possible applications of embodiments of the invention include (a) facilitating authentication and trust establishment in ad-hoc communities of users / devices; (b) improving distribution of media (e.g. Scalable Video) in regions where a wired or wireless ad-hoc network can be established among subscribers (that is devices such as wireless routers e.g. BT' s Home Hub) (c) improving security of messages broadcasted to or between device or user communities.

Embodiments of the invention will now be described, by way of example only, with reference to the following figures in which:

Figure 1 is a schematic diagram of a scalable video system in accordance with an embodiment of the invention;

Figure 2 depicts a one way key chain showing the direction of time; Figure 3 is a depiction of the generation of multiple key chain; and Figure 4 is a flow chart of a process in accordance with the invention.

Referring to Figure 1 there is shown a scalable video system 10 comprising a video server 12, scalability servers 16, subscriber computers 20 and a Key Distribution Centre (KDC) 22. In alternative embodiments the KDC 22 is not provided and its functions are provided by the one or more of the video server 12, scalability server 16 and subscriber computers 20.

The video server 12 comprises a conventional server typically including, a processor/CPU 102 with a clock 104, and memories 106 including a Random Access Memory and a hard disk. The server 12 broadcasts scalable video packets which may be encrypted. Additionally it adds authentication to the video packets using the process described below. This process uses key chains that are generated and stored by the video server 12.

The video server 12 has a first communication path 14 to the scalability servers 16 and a second communication path 26 to the Key Distribution Centre 24. The first communication path 14 allows the video server 12 to broadcast the scalable video and might typically comprise the Internet, a private network or communication satellites. The second communication path 26 is used to help verify the authentication of scalable video packets. The path 26 can be used for transferring data securely using for example a digital signature or the path 26 may include an authenticated channel such as by using Ipsec (EP security) or TLS (Transport Layer Security). All communications between KDC 22 and video server 12 are preferably confidential and authenticated, using for example a public key infrastructure.

There may be any number of Scalability Servers 16, though in Figure 1 three are illustrated. Each scalability server may comprise conventional computer hardware including a processor/CPU, and memories including a Random Access Memory and a hard disc. The scalability servers 16 are each connected via a third communication path 18 to at least one subscriber computer 20. Typically the third communication path includes one or more of the Internet and wireless networks, communication satellites or a mobile telephony network.

In a known manner, each scalability server 16 is programmed to receive scalable video packets from the Video Server 12, scale the packet up or down in size to meet the requirements of subscribers and to transmit this on to the subscriber computers 20 over third communication path 18. Additionally the scalability servers 16 are programmed to authenticate the scalable video packets to check that they are all coming from the same video server 12. In an alternative embodiment there is no authentication by the scalability server 12, with authentication occurring only at the subscriber end. In the preferred embodiment there is a two-layered approach with authentication taking place at the scalability server 16 end and at the subscriber computers 20. A benefit of the two- layered approach is that it becomes difficult for a third party to impersonate the video server 12 in the communication line both in first communication path 14 and third communication path 18.

The process described below allows the scalability servers 16 to perform authentication without much overhead and with little computational cost.

Subscriber computers 20 may comprise conventional computer or set top box hardware including a processor/CPU, and memories including a Random Access Memory and/or a hard disk. Some or all the computers 20 may be in the form of smart phones.

Typically there are a large number of subscriber computers 20 for each scalability server 16 but for clarity and ease of description only two are illustrated in Figure 1. A scalability server 16 may be provided for each possible size (or more generally resolution or quality) of scaled up or down video packet, with the subscriber computers 20 connected to the same scalability server 16 being computers designated to receive the video at the given size (resolution or quality) of that server 16 and preferably the size/resolution is optimal for the subscriber's computer's 20 capabilities. Alternatively the scalability server 16 to which a subscriber computer is connected may be based on the capabilities of data path 18 which could very for different computers 20 such as for smart phones connected to a 2.5G telephony network and others connected to a 3 G or HSDPA network.

The subscriber computers 20 are responsible for decrypting the scaled video packets to allow the video stream to be watched by end users. Preferably the subscriber computers 20 are only in communication with scalability servers 16 via path 18 and have no direct link to the video server 12. Whilst in some preferred embodiments authentication occurs at the subscriber end (e.g. the two layered approach) (in which case the subscriber computer provides inter alia the function of an authenticating receiver) it is possible due to the set up of system 10 to only authenticate at the scalability server's 16 end. Providing authentication only at the scalability server 16 allows less processing to be done by each subscriber computer 20 and also less load on communication path 18 each of which may be beneficial. Authentication for scalability servers 16 can be considered more important since they represent a single point of attack through which a third party could send unauthenticated video to multiple subscribers. Each scalability server 16 can be considered to provide, inter alia, an authenticating receiver - something which has application beyond the limits of providing server functionality. The Key Distribution Centre 22 may comprise conventional computer hardware including a memory and processor with a clock. As well as a connection 26 to video source 12, KDC 22 is connected to subscriber computers 20 via fourth communication path(s) 24, such as the Internet, and/or connected to scalability servers 16 via a fifth communication path 25, such as the Internet. The KDC 22 stores at least the last parts of key chains generated by the video server and time stamps of when each video packet was sent. The KDC 22 updates its time frame with respect to the video server 12. If the KDC 22 comprises more than one server/computer then their clocks are synchronized with the clocks of the video server 12. Use of the KDC 22 allows new subscribers to be added and to be able to authenticate, even though they have no direct communication with the video server 12, since they can be provided with the last key of a chain.

The system 10 authenticates video packets initially using the TESLA protocol but communicating between the component parts of system 100 as described below. The system 10 then generates and authenticates further key chains in an entirely new manner.

In Figure 2 is shown the order of generation and revealing of a key chain Ki to Ko following the TESLA protocols complete with suitable time intervals. The TESLA approach does not require strong time synchronization — it is sufficient for there to be loose time synchronization and for the receiver to know the upper bound on the sender's local time. If there is non-negligible clock drift at either the sender or receiver, the receiver will need periodically to re-synchronize with the transmitter. In loose time synchronization, as here, the receiver does not need to know the precise difference between the local times at the transmitter and at the receiver - it is sufficient for the receiver to know the upper bound of this error - the maximum time synchronization error Δ. In the TESLA approach each receiver performs explicit time synchronization with the transmitter, (the approach proposed in the TESLA paper, to which the reader is directed, is that earlier proposed by Reiter et al in M. Reiter, K. Birman, and R. van Renesse. "A security architecture for fault-tolerant systems". ACM Transactions on Computer Systems, 12(4):340-371, November 1994. In this approach a simple two-round time synchronization protocol is used to ensure that the receiver knows an upper bound on the sender's clock. In the protocol the receiver records its local time t_R and sends a time synchronization request, including a nonce, at time t_R, to the sender. (The security of. this time synchronization protocol relies on the unpredictability of the nonce - if an attacker could predict the receiver's nonce, it could send a time synchronization request to the sender with that nonce, and replay the response later to the receiver.) Upon receiving the time synchronization request, the sender records its local time ts and replies with a signed response packet containing ts and the nonce. When the receiver has its new current time t_r, it computes the upper bound on the current sender's time (t_s) as t_s <t_r - t_R + ts. The real synchronization error after this protocol is δ (the difference between t_R and ts). The receiver, however, does not know the propagation delay of the time synchronization request packet, so it must assume that the time synchronization error is Δ (or the full round-trip time (RTT)). (Note that the processing and propagation delay of the response message does not change δ (assuming that the sender immediately records and replies with the arrival time of the request packet), since the receiver is only interested in an upper bound on the sender's clock. If the receiver were interested in the lower bound on the sender's clock, the processing delay and delay of the response message would matter. For more details on this refer to the more detailed time synchronization description in the TESLA paper.) The sender S has a digital signature key pair, with the private key Ks^"1 and the public key Ks. The original TESLA approach assumes a mechanism that allows a receiver R to learn the authenticated public key Ks. The receiver chooses a random and unpredictable nonce. Before sending the first message, the receiver records its local time t_R.

R → S : Nonce

S → R : { Sender time t_s , Nonce} K₈ ^"1

Upon receiving the signed response, the receiver checks the validity of the signature and verifies that the nonce in the response packet equals the nonce in the request packet. If all verifications are successful, the receiver uses t_R and ts to compute the upper bound of the sender's time as described above.

As is conventional the time order of "generation" and "revealing" are in opposite directions with a one way hash function F being used to generate the key chain from a first key Ku By a one way hash function it is meant a function which generates the same output from identical inputs but for which it is very difficult or impossible to generate the input from the output even when the hash function is known. hi Figure 3 is shown the generation of second key chain M of keys Mt to Mo and third key chain N of keys Ni to No, from the first key chain K. hi Figure 4 is shown a process 100 of authentication of video packets from video source 12 at a scalability server 16 or subscriber computer 20.

First at step S 102 a first key Ki is generated by the video server 12. This may be generated randomly and can be of a predetermined length. Next at Step S 104 a one- way hash function F is used to generate next a second key Ku where Ki-I-F(Ki). As F is a one-way hash function it is very difficult to determine Ki from Ki-i whereas it is straightforward to generate Ki-i from Kt provided F is known.

At step S 106 the remainder of a key chain K shown in Figure 2 is generated. Each key in the chain is generated by further applying the one-way hash function F until a final key Xb is generated. The function F is applied i times to generate Ko, so

Each key in Figure 1 can be generated from the key shown immediately above it by application of function F a single time or by application of the function F x times on a key x places above it. Consequently all the keys in chain K can be generated from Ki, but Ki cannot be calculated from any other key and will be truly secret and unshared until it is revealed. Accordingly it can be verified that different keys belong to the same key chain e.g. by checking that a key Ki-x is indeed the xth key in the chain by checking that V^x(Kx)= Ko. AU the keys in the chain K, their order and the hash function F are stored in a memory (RAM, flash memory or harddisk etc) of video server 12. The final key Ko (which will be revealed first) is then sent at step S 107 to the

Key Distribution Centre 22 via secure path 26 using TLS, Ipsec or digital signatures. The video server 12 also determines a time scale for using chain K and determines the time intervals with which it will move from using the final key Ko to each further key along the reveal arrow 40 shown in Figure 1. The KDC 22 then calculates the maximum time intervals at which recipients should receive a video packet from the video source 12 with a given key based on the time periods calculated by the video source 12 and adding the expected time delay to reach the recipient. The recipient can be scalability servers 16 and/or subscriber computers 20 depending on the implementation. Where both scalability servers 16 and subscribers 20 authenticate, different maximum times will typically be calculated for each based on any assumed or determined knowledge of communication paths 14 and 18. The maximum times for different subscribers 20 can also vary depending on paths 18 such as for the example where mobile telephony networks of different speeds are connected to different scalability servers 14.

At step S 108 the video server 12 generates a message authentication code (MAC) using final key Ko using symmetric encryption. Next at step SIlO this MAC is attached to a base layer video packet and transmitted through path 14 to the scalability server 16 at which the video is then scaled and sent onto subscribers 20 in a conventional manner. A counter is also started for the number of keys sent and is set at "n=l".

At step S 113 the final key Ko is sent by or requested from the KDC 22 using a secure asymmetric system such as Ipsec or digital signatures. The recipient (server 16 or subscriber computer 20) can then check that the KDC 22 and video server 12 correspond by decrypting the MAC using the final key Ko and the use of the secure asymmetric protocol or authentic channel prevents a third party from transmitting this information. The hash function F is also provided to the recipient 16 or 20 and/or is stored at KDC 22 and requested when needed.

The hash function F can be provided to the subscriber by saving it or hardcoding it into the computer 20 at source rather than transmitting it remotely. For example where the subscriber computer 20 is a set top box the function can be provided hard coded into the set top box or on an encryption card, chip or module to be attached to it and sent by post or vehicular transport. This option reduces the likelihood of a third party gaining access to the hash function. Additionally with such embodiments the final key K₀ may be provided by similar method to the hash function such as a hard coding in a set top box, thereby obviating the need for step S 107, and asymmetric techniques, digital signatures or authenticated/secure channels such as IPsec.

Next at step Sl 14 there is a time delay d, equal to the time delay calculated by video server 12 at step S 107, before a different key is used. Depending on the comparative length of video packets and the predetermined time delays there can be additional video packets transmitted to recipients using the same MAC before the next key is used or the second video packet may use a MAC generated as described below.

At step Sl 16 the video server 12 generates a second MAC (preferably containing the same cleartext message) using the next key along the key chain in the "revealing" order which on the first application of step Sl 16 is key Ki. This is then attached to a scalable video packet at step Sl 18 and transmitted to recipients at step

S120. After the predetermined length of time which may be time delay d, no video packets from the video source will use the first MAC calculated from key Ko.

At step S121 the latest key used for creating a MAC, in this case Ki, is also sent to the recipient 16 or 20 either by the video server 12 or KDC 22.

At step S 122 the recipient then decrypts the MAC using the key, in this case Ki and checks the message is correct. The recipient then applies the hash function F to the latest key Ko (either in storage or from KDC 22), the appropriate number of times (which in this first case is once) and checks that this results in the final key Ko. The recipient also checks that the time at which the video packet was received was received within a time from receiving the base layer packet that is less than or equal to the maximum time allowed for that particular recipient calculated and stored by the KDC 22 at step S 107.

At step S125 it is determined whether n is greater than or equal to i-1, i.e. whether the counter has counted to i-1. If it is equal then the process 100 continues to step S 128. If n is less than i-1 then at step S 126 n is incremented by one and the process returns to step S114. The steps S114 to S125 are then repeated with key Kn and at step S 124 the hash function is applied n times to check that

On subsequent times through steps Sl 14 to step S 125 the importance of checking the time delay becomes clear. Once a key Kn is revealed to recipients, any third party posing as a recipient, that knows the one way hash function can generate all keys to below Kn on chain K in Figure 1 (i.e. all keys Kx where x<n). In practice a recipient 16 or 20 may temporary lose contact with video source 12 either by accident (such as a loss of reception on a smart phone) or by intention and miss packets of data. A third party which has received these packets can then use the keys to fool the recipient that packets from the third party using these keys are authentic. This is prevented by the time delay check since after a certain time the video source 12 will no longer use a key Kn and KDC 22 will inform the recipient that a given key Kn was received outside the maximum time delay and is therefore not to be trusted

Accordingly this TESLA chain uses time to produce asymmetry and therefore security, even though the keys and encryptions are symmetric. It also has the advantage that when intermediate values in the chain are not be received since all keys can be authenticated from final key Ko and the correct number of applications of function F (the correct number can be calculated by the time delay).

The time delay between steps Sl 12, S120 when video packets with MACs are sent and steps Sl 13 and S 121 when keys are sent can vary between different embodiments. In particular step S 113 can be merged with step S 120 and step S 121 merged with the next application of step S 120, that is the key with which a MAC was encrypted can wait to be sent with the next video packet/MAC.

Once n is equal to z-1, step S 128 is commenced. Notably in the last pass through step Sl 18 the second key Kι-i is revealed but the initial key Ki has not been sent and is still only known by the video server 12. At step S128 steps S102 to S108 are repeated but generating a new initial key Mt which in turn is used to generate a second key chain M as shown in Figure 3. The same one way hash function F is preferably used though a new function could be used provided it is provided to, accessible by or determinable by recipients 16/20.

Next at step S 130 a video packet with a MAC calculated from final key Mo of second key chain M is transmitted without need for any special security as was required for the base layer packet.

Next at step S 132 a message is sent which is calculated from encrypting or otherwise applying (such as multiplying) final key Mo of second chain M with key initial key Ki of first chain K. At step S 134 final key Mo of the second chain is sent allowing the recipient to check the MAC from step S 130. Notably when key Mo is sent to KDC 22 it does not need to be sent securely using Ipsec or with digital signatures etc. Steps S 132 and S 134 maybe performed simultaneously or even in the opposite order. At step S136 initial key Ki of first chain K is sent to the recipient 12 or 16 from the video server 12. Next at step S 138 the recipient authenticates the packet with the MAC using Mo is from the video server 12 by checking that encrypting or otherwise applying Mo with newly received Ki results in the message received at step S132. Since at step S132 the initial key Kt of the first chain K was still secret to all but video server 12, the message and new key MO belonging to the second chain M can only have come from the video sever 12. Knowledge of the initial key Ki was required for the message's calculation. Steps S136 and S138 can be reversed in order.

At step S 140 steps Sl 14 to S 120 are repeated but using the second chain M rather than the first chain K. This step allows the recipient to authenticate each packet as coming from the same source as the first revealed key of the second chain (final key Mo) which is known to be from the same source as the first key chain K. These steps can be repeated for an unlimited number of key chains each using the initial key of the previous chain to authenticate the final (and therefore first revealed) key of the next chain.

Accordingly multiple key chains can be used elongating the amount of time for which video can be authenticated and decreasing the chance of the authentication method being copied by an unauthorised party, whilst only requiring the base layer packets to be signed with a MAC using a key of the first key chain a secure asymmetric method or similar.

As discussed in the paper by Perrig et al, the keys used to compute the MACs appended to video packets may be derived from the keys of the key chain rather that using the keys from the key chain to compute the MACs directly. For example a oneway function can be applied to all of the keys in the key chain, with the resulting keys being used to compute the MACs.

Claims

1 A method of authenticating a second transmitted item received by a recipient as having come from the same source as a first transmitted item comprising the steps of: generating a first key, generating a first chain of one or more subsequent keys using one or more one-way functions, the one or more subsequent keys being generatable from the first key by applying the one or more one-way functions to the first key, storing the one or more subsequent keys in a memory, transmitting a first item with an element including, or derived using, a subsequent key, generating a second key not forming part of the first chain, sending a message calculated from the first key and the second key, transmitting a second item with an element including the second key, subsequent to broadcasting the first item, sending the first key to the recipient, subsequent to sending the message, the first key allowing the recipient to check that the message was calculated from the second and first keys and that the subsequent key received with the first item can be generated from the first key by one or more applications of the one or more one-way functions.

2. A method according to claim 1 wherein each subsequent key in the second chain is produced by an increasing number of applications of the one or more oneway functions, preferably wherein the same one-way function is included in every application, until a last key is produced.

3. A method according to claim 2 comprising the step of transmitting a plurality of earlier items before transmitting the first item, each of the plurality of earlier items being transmitted with an element including, or derived using, a subsequent key allowing authentication that they came from the same source as each other.

4. A method according to claim 3 wherein the elements including, or derived using, subsequent keys are transmitted in the reverse order of the number of applications of the one or more one way function needed to generate the keys from the first key, from the larger numbers to smaller numbers.

5. A method according to any preceding claim wherein the transmitted items are video packets and preferably scalable video packets.

6. A method according to any preceding claim comprising the steps of: generating a second chain of one or more subsequent keys using one or more one-way function, the one or more subsequent keys being generatable from the second key by applying the one or more one-way functions to the first key, transmitting a third item with an element including, or derived from, a subsequent key from the second chain, allowing the recipient to check that the subsequent key from the second chain can be generated from the second key by one or more applications of the one or more one- way functions.

7. A method according to claim 6 wherein the same one or more one-way functions are used for generating the first and second chains.

8. A method according to claim 7 or 8 wherein each subsequent key in the second chain is produced by an increasing number of applications of the one-way function(s), preferably including the same one-way function in every application, until a last key is produced.

9. A method according to claim 8 comprising the step of transmitting a plurality of later items after the third item has been transmitted, each of the plurality of later items being transmitted with an element including, or derived using, a subsequent key of the second chain, preferably with different keys for different items, allowing authentication that the later items came from the same source as each other.

10. A method according to claim 9 wherein the elements including, or derived using, subsequent keys are transmitted in the reverse order of the number of applications of the one or more one-way function needed to generate the keys from the second key, from the larger numbers to smaller numbers.

11. A method according to any preceding claim including the steps of determining a maximum time duration between a recipient receiving a transmitted item with an element including, or derived using, a first specified key and receiving a transmitted item with an element including, or derived using, a second specified key, and checking whether an element including, or derived using, the second specified key has been received in less than the maximum time period from receipt of an element including, or derived using, the first specified key.

12. A method according to any preceding claim wherein a transmitted item, preferably the earliest transmitted item, is sent to the recipient using an asymmetric security measure, such a digital signature, or sent over an authenticated channel, such as Ipsec or TLS, allowing the recipient to determine that subsequent transmitted items are from the same source as the item sent by the asymmetric measure or authenticated channel .

13. A method according to any preceding claim when dependent on claim 6 comprising the steps of generating a plurality of initial keys not belonging to a previously generated chain, generating a plurality of subsequent chains each of one or more subsequent keys using one or more one way function, the one or more subsequent keys of each chain being generatable from a different initial key by applying at least one of the one or more one-way functions to an initial key, transmitting a plurality of items with an element including, or derived using, a subsequent key from a chain, preferably transmitting at least one item for each chain with the subsequent key for an item for a chain being a subsequent key from that chain, the subsequent key allowing the recipient to check that the subsequent key from a chain can be generated from its corresponding initial key by one or more applications of one or more one-way functions.

14. A method according to claim 13 wherein the one or more one-way functions used for generating the different chains are the same for every chain and/or are oneway hash functions.

15. A method according to claim 13 or 14 wherein each subsequent key in each chain is produced by an increasing number of applications of the one-way function(s), preferably including the same one way function in every application, until a last key is produced for each chain.

16. A method according to claim 15 wherein a plurality of items are transmitted for more than one of and preferably each of the plurality of chains, each of the plurality of items being transmitted with an element including a subsequent key of the corresponding chain, preferably including different keys for different items, allowing authentication that they came from the same source as each other.

17. A method according to claim 16 wherein the elements including subsequent keys from the same chain are transmitted in the reverse order of the number of applications of the one or more one way function needed to generate the keys from the initial key, from the larger numbers to smaller numbers.

18 A method according to claim 17 wherein the elements including keys from different chains are transmitted in sets with the all elements corresponding to a chain being transmitted before the next elements of the next chain.

19. A method according to any preceding claim when dependent on claim 13 comprising the steps of : sending a second message calculated from the second key and an initial key , and sending the second key to the recipient, subsequent to sending the second message, allowing the recipient to check that the message can be calculated from the second and initial keys and that a subsequent key already received from the second chain can be generated from the second key by one or more applications of the one way function.

20. A method according to claim 19 comprising the steps of sending a plurality of additional messages each calculated from a different set of one initial key and one subsequent key from a different chain, the recipient having already been transmitted an element including, or derived using, a subsequent key generatable from the one initial key, and sending for each message sent, the one initial key, subsequent to sending the corresponding message, each one initial key allowing the recipient to check that the corresponding message can be calculated from the one initial key and subsequent key of a different chain, and that one or more subsequent keys already received from the corresponding chain can be generated from the one initial key by one or more applications of the one way function(s).

21. A transmission server for transmitting at least two items to a recipient which are authenticable as coming from the same source, the server comprising a processor and a memory, the server having a first key stored in the memory or the server being configured to generate a first key the server having a first chain of one or more subsequent keys generatable using one or more one-way functions stored in the memory, the one or more subsequent keys being generatable from the first key by applying the one or more one-way functions to the first key, the server being configured to transmit a first item with an element including, or derived using, a subsequent key, to send a message calculated from the first key and a second key not forming part of the first chain which second key is stored in the memory and/or generated by the server, to transmit a second item with an element including the second key, subsequent to transmitting the first item, and to send the first key to a recipient, subsequent to sending the message.

22. A computer program product comprising instruction which when run on computer apparatus provide the method server or receiver of any preceding claim.