WO2008037278A1

WO2008037278A1 - Method and system for secure transmission over the internet

Info

Publication number: WO2008037278A1
Application number: PCT/EP2006/009385
Authority: WO
Inventors: Diego Buffa; Andrea Bragagnini
Original assignee: Telecom Italia S.P.A.
Priority date: 2006-09-27
Filing date: 2006-09-27
Publication date: 2008-04-03

Abstract

A method for secure transmission over the internet comprises applying a cryptographic algorithm on a sequence of fragments of a data packet, wherein each fragment includes a respective payload and the cryptographic algorithm requires the payload of the fragment to be multiple of a cipher block size; the method comprises taking a current fragment (F1 ) from the sequence; checking if the size of the payload of the current fragment is multiple of the cipher block size; in the negative, extracting a part of said payload such that the size of the payload becomes multiple of the cipher block size; memorizing the extracted part; applying the cryptographic algorithm to the current fragment; and adding the extracted part to a subsequent fragment (F2) of the sequence.

Description

METHOD AND SYSTEM FOR SECURE TRANSMISSION OVER THE

INTERNET

DESCRIPTION

Background of the invention

Field of the invention

The present invention generally relates to methods for secure transmission over the internet, according to the IPsec international specifications.

Description of the related art

IPsec (IP security) is a standardized framework for securing Internet Protocol (IP) communications by encrypting and/or authenticating IP packets in data streams. In IPsec the ESP (Encapsulating Security Payload) protocol (specified in RFC 2406) provides a way to achieve authentication, confidentiality and integrity check in IP-based communication. In particular confidentiality is achieved using encryption algorithm with a secret key. The encryption engines specified in the standard are based on block cipher algorithms (AES - Advanced Encryption Standard, and DES - Digital Encryption Standard), which transform a "plaintext" into a "ciphertext", and wee versa. The block cipher algorithms typically require that packet data is a multiple of the block size (which is 8 bytes for DES and 16 bytes for AES). The term "size", referred to a packet or to a part of it, will be used to indicate the length thereof in terms of bytes.

The IP packet structure, as defined in IP protocol, is composed by two fields: the header and the payload. The header that is 20 byte long contains information relevant to the packet, like source and destination addresses and the carried protocol (e.g. TCP). The payload, whose length may differ from packet to packet, contains the message sent by the source host to the destination host.

When a packet is protected using the ESP protocol, a new header, called ESP header, is inserted between the IP header and the payload. The length of this header is 8 bytes. The carried protocol field of the IP header is replaced with the ESP protocol code (i.e. 50) and the original carried protocol code is appended to the payload. Since the encryption algorithms works on fixed blocks size, the original payload plus the carried protocol code must be "padded" until a multiple of the specified size has been reached (alignment operation). The padding data and the carried protocol code form a new section called ESP Trailer (ESPTR). The ESPTR is encrypted along with the payload, thus the size of the encrypted payload is of nx8 bytes (n being an integer).

Anyway, IP protocol allows packed data to be fragmented in several fragments when transmitted over the network; all the fragments except the last one must be a multiple of 8 bytes, which is the elementary fragment unit. Information about fragments size and sequence are kept in every fragment IP header (in "total length" and "fragment offset" fields). As will be explained in the following, this fragmentation may lead the ciphering and deciphering procedure to be quite complex without reassembling the packet.

The ESP protocol defines two modes of IPsec operation: transport mode and tunnel mode.

In transport mode only the payload (message) of the IP packet is encrypted, and the IP header is sent as plain text. Transport mode is typically used for host-to-host communications over a LAN.

In tunnel mode the entire IP packet is encrypted, and it must then be encapsulated into a new IP packet for routing operations. In other words, tunneling (or encapsulation) consists in wrapping a packet in a new one by attaching a new header to the original packet so that the entire original packet becomes the payload of the new one. Tunnel mode is typically used in packet-switched networks for network-to-network communications (secure tunnels between routers) or host-to-network and host-to-host communications over the Internet.

In the following the two modes (transport and tunnel) will be described by means of examples and, for each of them, the problems associated with encryption and decryption of IP fragments will be highlighted.

A further distinction will be made between packets outbound, generated locally and to be encrypted, and packets inbound, generated remotely and to be decrypted.

In particular, the following terminology will be used:

- IPSEC-TRANSPORT-AES-INBOUND: identifies transmission by transport mode, AES algorithm and packets inbound;

- IPSEC-TRANSPORT-AES-OUTBOUND: identifies transmission by transport mode, AES algorithm and packets outbound; - IPSEC-TUNNEL-DES-INBOUND: identifies transmission by tunnel mode, DES algorithm and packets inbound;

- IPSEC-TUNNEL-AES-INBOUND: identifies transmission by tunnel mode, AES algorithm and packets inbound.

In Figure 1 it is shown an example of transport mode and of a sub-part of a telecommunication system S allowing communications by transport mode. The illustrated part of the telecommunication system S comprises the internet network and a first and a second host H1 and H2 connected to such network.

Let suppose that the first host H1 has to send a data packet P to the second host H2 over the internet. The packet P comprises a 20-byte IP header and a payload. The packet P is transformed, according to the IPsec specification, into a new packet P_tran_sport having the same header, followed by the ESP header and a new payload obtained by encrypting the payload of the original packet and the ESP trailer (EPL - Encrypted Payload). The new packet P_transpo_rt to be sent through the network can be fragmented, as stated in the IP specification, in fragments with payload multiple of 8 bytes, except for the last fragment. Only two fragments F₁ and F₂ are shown in the illustrative example of Figure 1. The first fragment F₁ has a 20-byte IP header, a 8-byte ESP and a ax8-byte encrypted payload. The second fragment F₂ has a 20-byte IP header and a (n-a)xβ-byte encrypted payload.

In case of IPSEC-TRANSPORT-AES-INBOUND it can happen that it is not possible to decrypt some fragments in the second host H2 because the encrypted payload can have size different from a multiple of the encryption block size (16 bytes). For example, let consider the case of two fragments F₁ and F₂ as shown in Figure 2 arriving at the second host H2: even if they contain payloads (PL=ESP+EPL and PL=EPL+ESPTR, respectively) that are multiple of 8 bytes they might not have an encrypted payload (EPL and EPL+ESPTR, respectively) fitting the block size of 16 bytes.

In case of IPSEC-TRANSPORT-AES-OUTBOUND, the first host H1 may generate fragmented packets, or may deal with packets already fragmented, but it could be unable to encrypt some fragments because the fragments might not be multiple of the block size (16 bytes). Suppose for example that the first host H1 has to send to the second host H2 the four fragments F₁, F₂, F₃ and F₄ shown in Figure 3: even if the payloads (PL) are multiple of 8 bytes, they don't fit the block size of 16 bytes, and therefore cannot be encrypted as such.

In Figure 4 it is shown an example of tunnel mode and part of a telecommunication system S' suitable for tunnel mode transmission. The illustrated part of the telecommunication system S¹ comprises the internet network, a first and a second gateway GW1 , GW2 connected to such network, and a first and a second hosts H1 , H2 connected to the first and the second gateway GW1 , GW2, respectively.

As shown in Figure 4, the entire original packet P generated by host H1 is encrypted and inserted as the payload of a new packet P_tunnei- As stated above, the original packet must be padded if it is not a multiple of the encryption block size. The new packet P_tunnei will thus have a 20-byte IP header, a 8-byte ESP, a 20-byte encrypted IP header (derived from the original packet) and an encrypted payload. The part of the packet P_tmnei following the IP header has a size of nx8 bytes.

The new packet P_tUnn_ei to be sent through the network can be fragmented, as stated in the IP specification, in fragments with payload multiple of 8 bytes. In the illustrative example of Figure 4, only two fragments F₁ and F₂ are shown. The first fragment Fi has a 20-byte IP header, a 8-byte ESP and a axδ-byte encrypted payload (including the encrypted IP header (EIP) of the original packet). The second fragment F₂ has a 20-byte IP header and a (n-a)xδ-byte encrypted payload.

In case of IPSEC-TUNNEL-DES-INBOUND it happens that, after decryption by the second host H2, the fragments are not a multiple of 8 bytes, which is instead requested for further processing. Let consider for example the three fragments of Figure 5: even if the first fragment contains a payload (PL=ESP+EIP+EPL=80 bytes) that is multiple of the block size, the resulting fragment after decryption won't be a multiple of 8 bytes because it will be formed just of the decrypted EIP and EPL, as shown in Figure 6. In case of IPSEC-TUNNEL-AES-INBOUND both effects of IPSEC-TRANSPORT-

AES-INBOUND and IPSEC-TUNNEL-DES-INBOUND may happen: the payload of fragments that H2 receives might not be a multiple of the block size (16 bytes) and, even in case the payload is a multiple of the block size, it might happen that, after decryption by the second host H2, it is not a multiple of 8 bytes, which is instead requested for further processing. Let consider for example the two fragments Fi and F₂ of Figure 7a: even if they contain payloads (PL=ESP+EIP+EPL and PL=EPL+ESPTR, respectively) that are a multiple of 8 bytes, they don't fit the block size of 16 bytes; this case is the same of IPSEC-TRANSPORT-AES-INBOUND. Let now consider for example the two fragments of Figure 7b: even if the first fragment contains a payload (PL=EIP+EPL=80 bytes) that is multiple of the block size, the payload of the resulting fragment after decryption won't be a multiple of 8 bytes because it will be formed just of the decrypted EIP and EPL, as shown in Figure 7c.

Several documents treat the problem of packets fragmentation for IP security applications.

Patent application US2002/0015422 (published on February 7, 2002) relates to a cryptographic apparatus and a cryptographic communication system. The transmitting terminal is configured to determine if the packet must be split in fragments and, in the affirmative, to insert in the IP header of each fragment suitable information to allow restoring the IP data at the receiving terminal.

Patent application US2005/0060538 (published on March 17, 2005) relates to a method for processing fragmented datagrams, making use of offload engines. Data packets which become fragmented after encryption can be forwarded to a transport offload engine to be reassembled. The reassembled packets may be fed back to a security offload engine to be decrypted. The decrypted and reassembled packets may be forwarded again to the transport offload engine to extract the data payloads of the packets.

David A. Wagner, Steven M. Bellovin, "A "Bump in the Stack" Encryptor for MS- DOS Systems" (Proceedings of Symposium on Network and Distributed Systems Security, 1996) relates to an implementation of IP security by exploiting open interfaces. This article makes some considerations about fragmentation but only propose solutions on how to avoid fragmentation.

Summary of the invention

The Applicant has noticed that the prior art does tackle the problem of allowing encryption and decryption of fragments without reassembling them and has sought a solution to this problem, in particular a solution providing memory usage saving and more security feature if combined with a firewall working on not re-assembled decrypted fragments.

The Applicant has found that an efficient method for allowing encryption and decryption of fragments that don't fit block size comprises the following steps, to be iterated on a sequence of fragments related to a data packet:

• extracting from a current fragment payload the minimum part of data that makes the remaining part of the fragment payload a multiple of the cipher block;

• preferably memorizing the extracted part of the current fragment payload;

• decrypting/encrypting the current fragment payload deprived of the extracted part; and

• adding the extracted part to the next fragment payload, which will then be treated in turn as a current fragment.

In other words, if frm_n is the size of the n-th fragment payload, frmn is the size of the n-th modified fragment payload, bs is the block size and remainder a function that return the remainder of a division, the method provides for encrypting/decrypting a fragment with the following payload:

• frm1 =fιτn₁ - remainder{frm^bs)

then in the next step to encrypt/decrypt a fragment with the following payload:

• frm2= remainder^mybs) + frm₂- remainder{[remainder(frmi/bs) + frm₂]/bs},

and so on.

For fragments payload that after having been decrypted are not a multiple of 8 bytes, the method comprises the following steps, to be iterated on the sequence of fragments:

• extracting from the decrypted fragment payload the minimum part of data that makes the remaining part of the fragment payload a multiple of 8;

• memorizing the extracted part; and

• adding the extracted part to the next decrypted fragment payload.

Prerequisite for the solution is to process fragments in the due order.

The present invention thus relates to a method for secure transmission over the internet, comprising applying a cryptographic algorithm on a sequence of fragments of a data packet, each of said fragments including a respective payload, and the cryptographic algorithm requiring said payload to be a multiple of a cipher block size, wherein applying the cryptographic algorithm on the sequence of fragments comprises:

a) taking a current fragment from the sequence; b) checking if the size of the payload of the current fragment is multiple of the cipher block size; c) in the negative, extracting a part of the payload such that the size of the payload becomes multiple of the cipher block size; d) applying the cryptographic algorithm to the current fragment; and e) adding the extracted part to a subsequent fragment of the sequence.

Preferably, if the exit of step b) is positive, step b) is followed only by step d). The step c) is preferably followed by the step of memorizing the extracted part.

The steps a) to e) are advantageously iterated for each fragment of the sequence.

Preferably, the extracted part of the payload is the minimum part of the payload such that the size of the payload becomes multiple of the cipher block size.

Applying a cryptographic algorithm to the current fragment may comprise encrypting the current fragment. Alternatively, applying a cryptographic algorithm to the current fragment may comprise decrypting the current fragment.

The method may further comprise:

f) checking if the size of the payload of the decrypted current fragment is multiple of an elementary fragment unit; g) in the negative, extracting a part of the payload of the decrypted current fragment such that the size of the payload of the decrypted current fragment becomes multiple of the elementary fragment unit; and h) adding the extracted part of the payload of the decrypted current fragment to the subsequent fragment.

The step g) is preferably followed by the step of memorizing the extracted part.

The elementary fragment unit preferably consists of 8 bytes.

According to a further aspect thereof, the present invention relates to a device for secure transmission over the internet, comprising:

• an input module for the sequential input of fragments of a data packet, each fragment having a respective payload;

• at least a cryptographic module configured for sequentially receiving the fragments from the input module and for applying a cryptographic algorithm on the fragments, the cryptographic module requiring that the size of the payload is multiple of a cipher block size; and

• a check and resize module configured to interact with the input module for checking the size of the payload and for extracting a part of the payload if the size is different from a multiple of the cipher block size.

Preferably, the device further comprises:

• a buffer module, interposed between the input module and the cryptographic module, for memorizing the extracted part of the payload.

The at least a cryptographic module may comprises an AES module. In alternative or in addition, the at least a cryptographic module may comprise a DES module.

The check and resize module may be further configured for extracting a number of bytes from the payload of the fragments at the exit of the cryptographic module if the size of the payload is different from a multiple of an elementary fragment unit; moreover, the device may further comprise a buffer module for receiving and memorizing said number of bytes. Brief description of the drawings

The features and advantages of the present invention will be made clear by the following detailed description of an embodiment thereof, provided merely by way of non- limitative example; in the following description, reference will be made to the annexed drawings, wherein:

Figure 1 shows part of a telecommunication system suitable to work on transport mode, the processing of a packet to be transmitted by such a system and a fragmentation processing example; Figures 2 and 3 are illustrative examples of fragmentation of packets to be transmitted over the system of Figure 1 ;

Figure 4 shows part of a telecommunication system suitable to work on tunnel mode, the processing of a packet to be transmitted by such a system and a fragmentation processing example;

Figures 5, 6, 7a, 7b and 7c are illustrative examples of fragmentation of packets to be transmitted over the system of Figure 4;

Figure 8 shows schematically an encryption/decryption device according to the present invention, to be used in the systems of Figure 1 and 4; Figure 9 shows schematically the hardware architecture of a component of the device of Figure 8; and

Figures 10 to 15 show processing of packet fragments by the device of Figure 8. Detailed description of preferred embodiment(s) of the invention

Figure 8 shows an encryption or decryption device 100 according to the present invention, located inside an apparatus or a terminal suitable for encryption/decryption of packet data, such as for example hosts H1 and H2 in telecommunication system S of

Figure 1 or gateways GW1 and GW2 in telecommunication system S' of Figure 4.

Device 100 comprises three main modules:

- a fragment driver 10 (that can be SW or HW);

- a VPN (Virtual Private Network) engine 20 (that can be SW or HW); and

- a post-IPsec assembly 30.

The fragment driver 10 supplies to the fact that fragments of a same packet can arrive delayed and not in order, by storing them in a buffer (not shown) until all have arrived, and then ordering them. Once all the fragments belonging to a packet have arrived and reorganized, the fragment driver 10 sends them to the VPN engine 20.

The VPN engine 20 is configured to process the fragments in different manners depending on the type of protocol the fragment belongs to. The VPN engine 20 is also configured to send decrypted/encrypted packets to post-IPsec Assembly 30 for further processing.

The post-IPsec assembly 30 is in charge of other IPSEC-related operations for authentication and integrity check. It also collects the fragments to be send to other applications layers.

In a preferred embodiment, the fragment driver 10 and the post-IPsec assembly 30 are realized in software and the VPN engine 20 in hardware, so that the software is offloaded of all the process intensive tasks.

Figure 9 shows the hardware architecture of the VPN engine 20, according to a preferred embodiment of the present invention.

The VPN engine 20 is organized in several blocks in order to implement the different procedures that will be described in the following.

The VPN engine 20 comprises:

• an input memory 22, for storing a sequence of fragments, either to be encrypted or decrypted;

• a 8-byte buffer 23, for storing a surplus set of 8 bytes to be processed, as described in the following;

• a first demultiplexer 31 having one input and two outputs, the input being connected to the input memory 22, and a first output being connected to the buffer 23;

• a first multiplexer 32 having a first input connected to the output of the buffer 23 and a second input connected to a second output of the first demultiplexer 31 ;

• a second demultiplexer 33 having the input connected to the output of the first multiplexer 32;

• an AES module 24 connected to a first output of the second demultiplexer 33, for encrypting or decrypting fragments coming from the input memory according to the AES algorithm;

• a DES module 25 connected to a second output of the second demultiplexer 33, for encrypting or decrypting fragments coming from the input memory according to the DES algorithm;

• a second multiplexer 34 having a first input connected to the output of the AES module 24 and a second input connected to the output of the DES module 25;

• a third demultiplexer 35 having the input connected to the output of the second multiplexer 34;

• a 4-byte buffer 26 having the input connected to a first output of the third demultiplexer 35, for storing a surplus set of 4 bytes after decryption operation, as described in the following;

• a third multiplexer 36 having a first input connected to the output of the 4- byte buffer 26 and a second input connected to a second output of the third demultiplexer 35;

• an output memory, connected to the output of the third multiplexer 36, for collecting the processed fragments; and

• a packet builder finite state machine (FSM) 21 , controlling the overall functionality of the VPN engine 20 (including the operations of the different multiplexers and demultiplexers).

The VPN engine 20 is configured to process fragments according to the method of the present invention and is therefeore suitable to encrypt and decrypt fragments that don't fit the block size. In particular, given a sequence of fragments, the VPN engine 20 carries out the following steps:

• extracting from the payload of a current fragment in the sequence of fragments the minimum part of data that renders the remaining part of data a multiple of the cipher block;

• memorizing the extracted part in the 8-bytes buffer;

• decrypting/encrypting the current fragment so modified; and

• adding the extracted part to the next fragment, which is then in turn processed as a current fragment according to the above.

In other words, if frm_n is the n-th fragment fed in input to the VPN engine 20, bs is the block size (8 bytes for DES and 16 bytes for AES) and remainder a function that return the remainder of a division, the method provides for encrypting/decrypting the following fragment payload:

• frm 1 =frm 1 - remaindertfrm 1 /bs), then, in the next step, for encrypting/decrypting the following fragment payload:

• frm2= remainderffrnVbs) + frm₂- remainder{[remainder(frmi/bs) + frm₂]/bs},

and so on.

In case of fragments that after having been decrypted have a payload that is not a multiple of 8 bytes, the method comprises the following iterative steps:

• extracting from the current fragment payload the minimum part of data that makes the remaining part of the payload a multiple of 8 bytes,

• memorizing the extracted part in the 4-byte buffer; and

• adding the extracted part to the next fragment decrypted payload; the next fragment is then processed in turn as a current fragment according to the above.

In particular, the VPN engine 20 operates as follows.

In both packets inbound and outbound operations, the fragments to be encrypted or decrypted are fed to the input memory 22 so as to be processed in sequence. In case of AES operations, the packet builder FSM 21 checks if the 8-byte buffer 23 contains 8 bytes from the previous fragment. In the affirmative, the 8 bytes are taken from the 8- byte buffer 23 and sent to the AES module 24 via the first multiplexer 32 and the second demultiplexer 33, so that they can then be included in the current fragment. The packet builder FSM 21 also checks if the current fragment payload, when combined with the 8 bytes transferred to the AES module 24, will have a size multiple of the block size. In the negative (i.e., in case of 8 bytes in surplus), the 8 bytes in surplus are extracted from the current fragment in the input memory 22 and are sent to the 8-byte buffer 23 via the first demultiplexer 31 , so as to be available for the next fragment. The current fragment payload (possibly deprived of the above 8 bytes in surplus) is then sent to the AES module 24 via the first demultiplexer 31 , the first multiplexer 32 and the second demultiplexer 33. The AES module 24 adds the 8 bytes of the previous fragment to the current fragment and then processes the current fragment payload according to the AES algorithm, for encryption or decryption thereof.

In case of DES operations (for both packets inbound and outbound operations), the current fragment payload to be processed is sent directly from the input memory 22 to the DES module 25 via the first demultiplexer 31 , the first multiplexer 32 and the second demultiplexer 33. The DES module 25 processes the current fragment payload according to the DES algorithm, for encryption or decryption thereof.

In case of packets inbound (for both AES and DES operations), the packet builder FSM 21 checks if the 4-byte buffer 26 contains 4 decrypted bytes from the previous decrypted fragment payload (which bytes must be combined with the current decrypted fragment payload). In the affirmative, the 4 decrypted bytes are taken from the 4-byte buffer 26 and sent to the output memory 27 via the third multiplexer 36. The current decrypted fragment payload is then sent to the output memory 27 via the second multiplexer 34, the third demultiplexer 35 and the third multiplexer 36, where it is combined with the 4 decrypted bytes extracted from the previous fragment decrypted payload, if these are present. Before sending the current decrypted fragment payload to the output memory 27, the packet builder FSM 21 also checks if the current fragment payload (elaborated by AES module 24 or DES module 25) would have in the output memory 27, after the possible combination with the 4 decrypted bytes extracted from the previous fragment, a size multiple of 8 bytes. In the negative, the 4 bytes in surplus are extracted from the current fragment and are sent to the 4-byte buffer 26 via the second multiplexer 34 and the third demultiplexer 35, so as to be available for the next fragment.

Finally the packet builder FSM 21 builds the IP header for the output fragments accordingly to the protocol and the direction, and it updates the IP header total length and fragment offset fields accordingly to the operation previously accomplished.

The method of the present invention will be further illustrated by way of specific examples.

In case of IPSEC-TRANSPORT-AES-OUTBOUND, it can happen that it is not possible to encrypt some fragments because they have a payload that is not multiple of the block size (16 bytes). Let consider for example the four fragments (F₁-F₄) of Figure 3, and suppose that these fragments are received by the fragment driver 10 of the first host H1 and opportunely reorganized. The reorganized fragments are then passed sequentially to the VPN engine 20 to be encrypted. The operations carried out on the four fragments inside the VPN engine 20 are herein below described with reference to

Figure 10.

The first fragment Fi comprises a payload PL that in not multiple of 16 bytes (the block size). The VPN engine 20 therefore encrypts the maximum payload that fits a multiple of 16, in this case 96 = 6*16, and stores in the 8-byte buffer the 8 bytes of surplus.

When the VPN engine 20 has to encrypt the second fragment F₂, it inserts at the beginning of its payload the 8 bytes extracted from the first fragment F₁ and stored in the 8-byte buffer. In the specific example, the payload of the second fragment F₂ becomes 104+8 = 112 = 7*16. The second fragment F₂ so modified has therefore a payload that is a multiple of 16 bytes and the fragment F₂ can therefore be encrypted without a previous extraction of bytes.

The VPN engine 20 will then treat the third fragment F₃ as the first one: 8 surplus bytes are extracted from the third fragment F₃ and memorized in the 8-byte buffer, and they are then added to the payload of the fourth fragment F₄. In addition, the VPN engine 20 adds to the payload of the fourth fragment F₄ 6 bytes of ESP trailer, including the pad to round off the payload to the closest multiple of 16 bytes. The encrypted packet F₀₄ therefore reaches a dimension of 66+8+6 = 80.

In case of IPSEC-TRANSPORT-AES-INBOUND, it can happen that it is not possible to decrypt some fragments because the size of their payload is not a multiple of the block size (16 bytes). Consider for example the two fragments Fi and F₂ of Figure 2, and suppose that these fragments have been received by the fragment driver 10 of the second host H2 and opportunely reorganized. The fragments F₁ and F₂ are then passed sequentially to the VPN engine 20 to be decrypted. The operations carried out on the two fragments F₁ and F₂ inside the VPN engine 20 are herein below described with reference to Figure 11.

The first fragment F₁ comprises an encrypted payload EPL whose size is not a multiple of 16 bytes (the block size). The VPN engine 20 will then extract from the first fragment F₁ the 8 surplus bytes, so as to reduce the size of the first fragment F₁ to a multiple of the block size, in this case 96 = 6^*16. The 8 bytes of surplus are stored in the

8-byte buffer, while the first fragment Fi so modified is decrypted by the AES module.

When the VPN engine 20 has to decrypt the second fragment F₂, it will first add at the beginning of its payload the 8 bytes extracted from the first fragment F₁. The size of the second fragment F₂ in the specific example becomes 8+88=96=6^*16 and can be decrypted by the AES module. The output, deprived of the ESP trailer, is fragment F₀₂.

In case of IPSEC-TUNNEL-DES-INBOUND, it happens that after decryption the size of one or more fragment payloads is not a multiple of 8 bytes, which is instead required for further processing. Consider for example the three fragments F₁, F₂ and F₃ of Figure 5. Even if the first fragment F₁ contains a payload (PL=ESP+EIP+EPL) whose size (80 bytes in this case) is a multiple of the block size (8 bytes), the resulting fragment after decryption has a payload that is not multiple of 8 bytes, because it is formed just of the decrypted EPL (52 bytes in the present case). The operations carried out on the three fragments F₁, F₂ and F₃ inside the VPN engine 20 are herein below described with reference to Figure 12.

After the first fragment F₁ has been decrypted, the VPN engine 20, after having determined that the first fragment has bytes in surplus, extracts from the first fragment F₁ the minimum amount of packet data (4 bytes in this case) that subtracted to the first fragment F₁ yields its payload to be a multiple of 8 bytes, and stores the extracted bytes in the 4-byte buffer 26.

The stored data are then added to the payload of the second decrypted fragment F₀₂, whose size becomes 84 bytes in this case, which is not a multiple of 8 bytes. The second decrypted fragment F₀₂ is therefore in turn deprived of 4 bytes, i.e. of the minimum amount of packet data required to have a size that is multiple of 8 bytes. Again, this extracted fragment portion is stored in the 4-byte buffer, and is then added to the payload of the third decrypted fragment F₀₃. Finally, there is the extraction of the ESP trailer from the third fragment F₀₃.

In case of IPSEC-TUNNEL-AES-INBOUND, it can happen that the fragments payloads are not a multiple of the block size. In particular, even if the received fragments contain payloads that are multiple of 8 bytes, these payloads might not fit the block size of 16 bytes. Consider for example the three fragments F₁, F₂ and F₃ of Figure 13.

The first fragment F₁ comprises an encrypted payload (PL=EIP+EPL=72) that is not multiple of 16 bytes. The operations on the first fragment F₁ are illustrated in Figure 14. The VPN engine 20 extracts from the first fragment F₁ the minimum data (8 bytes) allowing the payload of the first fragment to be a multiple of 16 bytes, stores in the 8-byte buffer the 8 bytes of surplus, and decrypts the payload so reduced (having size of 64=4^*16 bytes). However, the first fragment F₁ so decrypted has a payload that is not multiple of 8 bytes (44 = 52-8 = 5^*8+4), and the VPN Engine 20 therefore stores in the 4- byte buffer 26 the last 4 decrypted bytes of the first fragment F₁ and passes to the fragment driver 10 a specification compliant packet Foi, having a 20-byte IP header and 40-byte payload.

The operations on the second fragment F₂ are illustrated in Figure 15. The second fragment F₂ comprises an encrypted payload of 80 bytes, which is multiple of the block size (16 bytes), but the addition of the 8 bytes extracted from the first fragment F₁ makes it no more multiple of the block size. The VPN engine 20 therefore extracts 8 bytes from the second fragment F₂ and stores them in the 8-byte buffer 23, and then decrypts the second fragment F₂ so reduced, having now a payload (80=5*16 bytes) multiple of the block size.

Once the second fragment F₂ has been decrypted, the 4 decrypted bytes extracted from the first fragment F₁, stored in the 4-byte buffer, are added to the beginning of the second fragment's decrypted payload; as a result, the second fragment F₂ has a payload that is no more a multiple of 8 bytes, and the VPN Engine 20 will then extract and store the last 4 decrypted bytes of the second fragment F₂ so as to be able to pass to the fragment driver 10 a specification compliant packet F₀₂, having a 20-byte IP header and 80-byte payload.

The operations on the third fragment F₃ are illustrated in Figure 16. The third fragment F₃ comprises an encrypted payload that is not a multiple of 16 bytes (EPL=72), but by adding the 8 bytes extracted from the payload of the second fragment F₂ it reaches the required size to be entirely decrypted. The VPN engine 20 will therefore decrypt the payload, taking into account the ESP trailer in accordance to the protocol specification. The 4 decrypted bytes stored from the second fragment F₂ are then added to the beginning of the payload of the third fragment F₃, and the resulting third fragment Fo₃ is sent to the fragment driver 10.

Claims

1. A method for secure transmission over the internet, comprising applying a cryptographic algorithm on a sequence of fragments of a data packet, each of said fragments including a respective payload, and the cryptographic algorithm requiring said payload to be multiple of a cipher block size, wherein applying the cryptographic algorithm on the sequence of fragments comprises: a) taking a current fragment from said sequence; b) checking if the size of the payload of the current fragment is multiple of the cipher block size; c) in the negative, extracting a part of said payload such that the size of said payload becomes multiple of the cipher block size; d) applying the cryptographic algorithm to the current fragment; and e) adding the extracted part to a subsequent fragment of the sequence.

2. The method of any of the preceding claims, wherein if the exit of step b) is positive, step b) is followed only by step d).

3. The method of claim 1 , wherein the step c) is followed by the step of memorizing the extracted part.

4. The method of claim 1 or 2, wherein the steps a) to e) are iterated for each fragment of the sequence.

5. The method of claim 1 , wherein said part is the minimum part of said payload such that the size of said payload becomes multiple of the cipher block size.

6. The method of any of the preceding claims, wherein applying a cryptographic algorithm to the current fragment comprises encrypting the current fragment.

7. The method of any of claims 1 to 5, wherein applying a cryptographic algorithm to the current fragment comprises decrypting the current fragment.

8. The method of claim 7, further comprising: f) checking if the size of the payload of the decrypted current fragment is multiple of an elementary fragment unit; g) in the negative, extracting a part of the payload of the decrypted current fragment such that the size of the payload of the decrypted

5 current fragment becomes multiple of the elementary fragment unit; and h) adding the extracted part of the payload of the decrypted current fragment to said subsequent fragment. 0 9. The method of claim 8, wherein the step g) is followed by the step of memorizing the extracted part.

10. The method of claim 8, wherein the elementary fragment unit consists of 8 bytes.

11. A device for secure transmission over the internet, comprising:

• an input module (22) for the sequential input of fragments of a data packet, each fragment having a respective payload;

• at least a cryptographic module (24, 25) configured for sequentially o receiving said fragments from the input module and for applying a cryptographic algorithm on said fragments, said cryptographic module requiring that the size of the payload is multiple of a cipher block size; and

• a check and resize module (21 ) configured to interact with the5 input module for checking the size of the payload and for extracting a part of the payload if said size is different from a multiple of the cipher block size.

12. The device of claim 11 , further comprising: 0 • a buffer module (23), interposed between the input module and the cryptographic module, for memorizing the extracted part of the payload.

13. The device of claim 11 or 12, wherein the at least a cryptographic module (24, 5 25) comprises an AES module (24).

14. The device of anyone of claims 11 to 13, wherein the at least a cryptographic module (24, 25) comprises a DES module (24).

15. The device of claim 11 , wherein said check and resize module (21) is further configured for extracting a number of bytes from the payload of the fragments at the exit of the cryptographic module (24, 25) if the size of the payload is different from a multiple of an elementary fragment unit, and wherein the device further comprises a buffer module (26) for receiving and memorizing said number of bytes.