Otros compromisos relacionados con Norgener S.p.A:

On the right side of figure5.4the new functionalities for data path handling are shown. S- SCTP defines two new blocks in the data path handling: the encryption/decryption block provides message confidentiality and the authentication block provides message integrity and origin authentication. The encryption/decryption block is integrated before bundling to allow to encrypt selected data chunks only. This provides S-SCTP with the ability to mix secure and insecure messages. The authentication block is integrated after bundling to minimise transmission overhead, and an HMAC [41] is computed over the whole SCTP packet including all chunks and the common header (figure3.1).

Figure 5.5: S-SCTP packet assembly

Secure data transport

Figure5.5shows the packet assembly process in more detail for security level 2 where data chunks are encrypted selectively, because this level requires the most complex processing. Chunks that are available for sending, and which are to be encrypted (see darker chunks in figure5.5), are grouped together with the newly defined padding chunk to form a newly defined chunk type called Encrypted Data chunk (EncData). Insertion of a PADDING chunk is done depending on data length and encryption block size. The EncData chunk is placed after (unencrypted) control chunks. If space is left in the packet, any data chunks that need not be encrypted can be added (see for example DATA chunk 2 in figure5.5). On the receiver side, after decryption of the EncData chunk, chunks could be out of sequence. But the SCTP packet disassembly part orders all DATA chunks anyway and delivers them to the upper layer in the right sequence.

After adding the SCTP common header, the HMAC is computed over the whole packet and appended in the newly defined, fixed size Authentication chunk (AUTH chunk) at the end of the packet. This is done before computing the packet checksum and inserting it into

the appropriate field in the SCTP common header. Therefore, the checksum is the only field not protected by the HMAC and has to be disregarded when checking the HMAC at the receiver.

The integration of encryption and HMAC calculation clearly optimises the transmis- sion overhead and the computational effort. Moreover, S-SCTP packets are self-contained in the sense that all information required to decrypt and verify them is included in the same packet. The allocation of the cryptographic functions to the packet assembly and disassembly module also fully avoids any problems related to multiple streams and order of delivery, as well as to multiple IP addresses and dynamic address reconfiguration (see section4.3).

Figure 5.6: Format of the S-SCTP EncData chunk

The format of an EncData chunk2 _{is shown in figure 5.6. It contains (in cleartext) the} chunk length, a random number and its length in bytes, a reference to a master secret key, and the payload field for the encrypted data. With the reference to the master secret key, the receiver of an EncData chunk is able to decide which set of keys was used for encryption and authentication, since during the lifetime of a secure session the keying material between client and server may be updated several times, each time leading to a different set of master secrets. The initialisation vector needed for Cipher Block Chaining (CBC) encryption and decryption of the payload is derived in a cryptographically secure way from:

2_{Each row in this representation indicates 32 Bit, the rows are transmitted in sequential order with the}

1. a shared master secret which is computed after the secure session setup, and 2. the random number transported in cleartext by the EncData chunk.

A similar approach is used for IPsec’s ESP. High quality random numbers of a suffi- cient length must be used, e.g. 64 bits or longer (see also [22] for necessary properties of random numbers).

The format of PADDING chunks is very simple, it only contains a common chunk header and a random number.

Figure 5.7: Format of the S-SCTP Authentication chunk

The format of an AUTH chunk is shown in figure 5.7. It contains (in cleartext) the chunk length, a reference to a master secret key and the authentication code. The reference to a master secret key is the same as in an EncData chunk.

S-SCTP uses user data compression to transport data before building a data chunk. When user data is compressed the data chunks include a compression flag. In standard SCTP, a data chunk has 5 flag bits reserved and the fourth bit is used for compression. Compression is performed before fragmentation (if necessary).

When the receiver detects a data decryption or a decompression failure then it discards the EncData chunk. When the receiver detects an authentication failure then the whole packet is discarded.

S-SCTP packet format and security levels

The S-SCTP packet format varies slightly at every security level. Figure 5.8 shows all packet formats in the different security levels.

In security level 0, the packet format is same as the standard SCTP packet format. In security level 1, every outgoing S-SCTP packet must include an AUTH chunk, which is added at the end of the packet. The advantage compared to TLS over SCTP is

Figure 5.8: Packet format in different security levels

that it also authenticates SCTP control chunks and common header whereas they remain unprotected in TLS.

In security level 2, S-SCTP has two packet formats. One is shown in figure 5.8, and describes the packet if an encrypted data chunk exists. If a packet doesn’t include an EncData chunk, then the packet format is the same as in security level 1.

In security level 3, every S-SCTP packet includes both EncData and AUTH chunks. This is the strongest security level and the original information is only visible at the two associated endpoints. For example, when a new IP address is added to an existing associ- ation, a third party cannot know this.