The present disclosure relates to sending encrypted transmission across networks, and in particular, across optical transport networks.
Optical transport networks (“OTNs”) are data networks comprised of optical elements connected by optical fiber links. OTNs are able to provide Dense Wavelength Division Multiplexed (DWDM) links to allow for high data rates, multiplexing, switching management, supervision, and survivability of optical channels of the signals they transport. Given their high data rates, OTNs are well suited for applications requiring large data transmissions across great distances.
OTNs deploy optical fibers over large geographical areas, often crossing national boarders to connect OTN nodes in different countries. At times, it is necessary for the optical fibers to be deployed across areas in which it is difficult to provide secure access to the fibers. Also, it will sometimes be necessary to deploy the fibers across unfriendly, or hostile territories. Given the large geographical area covered by OTNs, and the possibly unfriendly territory through which the fibers are deployed, OTNs may be exposed to eavesdroppers and hijackers. Additionally, given the high data rates of OTN networks, data security and authentication are particularly difficult to implement in OTN data transfers.
Data to be transmitted across an Optical Transport Network (OTN) is encrypted with a non-malleable encryption algorithm. An authentication code is generated to allow authentication of the data with a low latency encryption algorithm. A packet is generated that is configured to be transferred across the OTN and contains the encrypted data and the authentication code, and the packet is transmitted across the OTN. Analogous techniques are presented herein for decryption operations performed at the receive side.
Referring first to
Upon completion of the encoding and providing of the authentication code, the encryption logic 120 generates a packet 130 for transmission across the OTN on one or more optical fibers 140. The packet 130 is received by decryption logic 150, decrypted and supplied to the receiver (intended destination) 160. More specifically, the decryption logic 150 will decrypt the non-malleably encrypted data. The decrypted data will be authenticated using the authentication code received in the data packet 130.
Turning to
In step 220, an authentication code is provided for authentication of the data with a low latency authentication algorithm. For example, the authentication code may be included in the encrypted data, or alternatively, the authentication code may be provided separately from the data. According to various examples, the authentication code may take the form of a Galois Counter Mode (GCM) authentication code, or a Galois Message Authentication Code (GMAC). If the authentication code is included in the encrypted data, it may take the form of a string of predetermined characters, such as a string of zeros, or a checksum.
In step 230, a packet is generated that is configured to include the encrypted data and the authentication code. Examples of the packet generation operation will be described in greater detail below, in reference to
Reference is now made to
An attacker 330, though unable to decrypt cipher text 320, may attempt to cause predictable changes in the ciphertext 320 by, for example, flipping particular bits 340 of the cipher text. If the plaintext 300 is encrypted according to a malleable encryption algorithm, when the decryption operation 350 decrypts ciphertext 320, the attacker 330 may be able to insert predictable, malicious code into the plaintext 360. In contrast, if the encryption operation 310 uses a fully non-malleable encryption algorithm, any change 340 made by attacker 330 will result in the entirety 370 of decrypted plaintext 360 appearing as random or pseudo-random plaintext.
Next, with reference to
A specific example of a limited non-malleable encryption algorithm is a ciphertext stealing (XTS) encryption algorithm, or more specifically, an XTS encryption algorithm implemented according to the Advanced Encryption Standard (AES). Even more specifically, the XTS-AES encryption may be implemented according to IEEE P1619.1 standard.
Turning now to
A specific example of a partially non-malleable encryption is the block cipher mode of operation described in detail below.
Let P1, P2, . . . , Pmεf{0; 1}w denote plaintext blocks, and C1, C2, . . . ; Cmε{0; 1}w denote ciphertext blocks. Furthermore, let X0, X1, . . . ; Xm, Y0, Y1, . . . ; Ymε{0; 1}w be internal variables. P and C denote the plaintext and ciphertext, where P=P1∥P2∥ . . . ∥Pm and C=C1∥C2∥ . . . ∥Cm.
A·B and AB denote multiplication and addition in GF(2w), respectively. Note that addition and subtraction in GF(2w) are identical. The encryption and decryption operations utilize three key values: A;Bε{0; 1}w, and a block cipher key K. The encryption of a value Xε{0; 1}w by the block cipher, using the key K, is denoted as EK(X), and the decryption of X with the key K is denoted as EK−1 (X).
The full mode of operation is as follows. The encryption of a plaintext P using keys K, A, B is denoted as enc(K; A;B; P) and works as:
The decryption of a ciphertext C using keys K, A, B is denoted as dec(K; A;B; P) and works as:
Furthermore, let P, P′ be two distinct plaintexts, with j as the smallest index such that Pj≠Pj′. If we define:
δPi=Pi⊕Pi′
δXi=Xi⊕Xi′
δYi=Yi⊕Yi′
δCi=Ci⊕Ci′.
then, considering the encryption of P and P′, these variables are given by:
Similarly, for decryption, we let C, C′ be two distinct ciphertexts, and let j be the smallest index such that Cj≠Cj′, the above listed variables are given by:
As can be seen from the above, if an attacker modifies block j of a valid ciphertext C (and possibly other blocks after that one), resulting in a bogus ciphertext C′, then the post-decryption plaintext blocks following the changed block will be different, and will be pseudorandom. In other words, and with reference to
As explained above, the encryption operation can only be applied to plaintexts that are block-aligned. Nevertheless, partially non-malleable encryption can be extended so that it can handle non-aligned plaintexts, through mechanisms, such as block padding. For example, one suitable method is to append to the plaintext a single bit equal to one, followed by enough zero bits to fill out the block; if the message ends on a block boundary, a whole block of zeros is added. The encryption operation can also be extended so that it provides authentication on additional data that is associated with the message that is being encrypted. This can be done by adapting the encryption operation so that the initial variables X0 and Y0 depend on the associated data and on a secret key.
Reference is now made to
While
After encryption has been applied to plaintext 615, encryption module 610 outputs ciphertext 320. In the example depicted in
Authentication module 620 receives ciphertext 320 in order to provide an authentication code 622 to allow for authentication of the data with a low latency authentication algorithm. Authentication module 620 also receives initialization vector 611, nonce 612 and third key 621. According to the exampled depicted in
The authentication code 622 provided by the authentication module 620 may be, for example, a GMAC authentication code. A GMAC authentication code can be efficiently pipelined at the decoder/decryption logic, and therefore, may operate at speeds sufficient to meet the needs of the OTN data rates.
The authentication module 620 may be incorporated within the encryption module 610. For example, if partially non-malleable encryption is being applied to the plaintext 300, the authentication code 622 may take the form of a string of characters, such as a string of zeros, or a checksum. According to this example, the authentication code 622 may be appended to the end of the plaintext 300. When the ciphertext 320 is transmitted across the OTN without any changes by an attacker, upon decryption, the authentication code 622 will appear as the expected string of characters or checksum. Alternatively, if a change is made to the ciphertext 320, the authentication code 622 will no longer be the expected string of characters or checksum, but will instead appear as random or pseudo-random plaintext.
Once the authentication code 622 is provided, it is passed to packetization module 630. According to the example depicted in
While
Turning now to
The initialization vector 611 may be used as the initialization vector for both the non-malleable encryption and the low-latency authentication algorithm. For example, the initialization vector operates as a 64-bit linear feedback shift register, which shifts for every 128 bits of payload. Accordingly, as described above in reference to
Payload portion 132 may comprise the data of, for example, four OTN frames 701-704. According to this example, the payload portion 132 may be very large. Specific examples may include payload portions 132 which have 60928 bytes of data, or more. Or course, the payload portions 132 may contain less data.
The tailer portion 133 comprises an encapsulated security payload tailer which includes authentication code 622. In other examples, such as those implementing partially non-malleable encryption and which use a predetermined string of characters as an authentication code 622, the authentication code 622 may be included in the encrypted data of the payload portion 132.
As shown in
Sequence number 631 is used to both generate the authentication code 622, and to authenticate the data once the data reaches the receiver. The sequence number is a sequential value that is incremented every packet, and is set to zero when the key is changed. Accordingly, the sequence number will be incremented for every 128 bits of payload during the generation of the authentication code 622, and during authentication at the receiver.
Referring now to
In step 820, the encrypted data is decrypted to generate decrypted data. The decryption operation may be performed according to a fully non-malleable algorithm, a limited non-malleable algorithm such as XTS-AES, or a partially non-malleable algorithm, such as the block cipher mode of operation described above.
In step 830, the decrypted data is authenticated using an authentication code contained in the packet. The authentication may comprise evaluating the encrypted data to determine whether any changes were made. For example, the encrypted data may undergo the same authentication process that was completed by the sender of the data. If the authentication code determined by the receiver is the same as the authentication code sent in the packet, it may be determined that the received encrypted data is the same as the encrypted data that was sent by the sender, i.e., the data is authenticated. Alternatively, authenticating may involve evaluating the decrypted data. For example, when the received data has been encrypted according to a partially non-malleable algorithm, authenticating the data in step 830 may comprise evaluating the decrypted data to determine if a predetermined string of characters is present in the decrypted data. If the predetermined string of characters is present in the data, it may be determined that the encrypted data received in step 810 is the same encrypted data that was originally sent.
Turning now to
While
The authentication module 920 shown in
The authentication module 920 may perform the same authentication on ciphertext 320 that was performed by the sender of the packet. The authentication module 920 may then compare the results of the authentication with the received authentication code 622. If the authentication performed at authentication module 920 results in the same authentication code as received authentication code 622, it may be determined that the received ciphertext 320 is the same as the ciphertext sent by the sender.
In another example, authentication module 920 may receive the decrypted plaintext 360 instead of ciphertext 320. For example, if the ciphertext 320 has been encrypted accordingly to a partially non-malleable encryption algorithm, and the authentication code 622 comprises a predetermined string of characters, authentication module 920 may receive decrypted plaintext 360 to determine if the predetermined string of characters is present at the end of the plaintext 360. If the predetermined string of characters is present at the end of plaintext 360, it may be determined that the received ciphertext 320 is the same as the ciphertext sent by the sender.
The authentication module 920 may also control whether or not data should be received from a specific connection. For example, as the authentication module 920 detects authentication failures, after a threshold number of failures is met (typically a low number such as four), the authentication module 920 may indicate that the receiver should stop accepting data across the connection until new master keys 711-713 (
While
Reference is now made to
Memory 1050 may comprise read only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical or other physical/tangible (e.g. non-transitory) memory storage devices. Thus, in general, the memory 1050 may comprise one or more tangible (non-transitory) computer readable storage media (e.g., a memory device) encoded with software comprising computer executable instructions.
The encryption logic 120 and/or decryption logic 150 may be embodied as software instructions stored in memory 1050 and executed by processor 1040 to perform the operations described herein in connection with
There are several advantages to the techniques described herein. Specifically, through the use of non-malleable encryption, origin authentication, data integrity and anti-replay protection may be provided for OTNs over DWDM links. For example, by using fully, limited and partially non-malleable encryption algorithms, data that has been modified by an attacker may be discarded by the decryption module. However, the use of non-malleable encryption ensures that the attacker cannot manipulate the data to be a non-arbitrary value. While using fully non-malleable encryption will provide exceptional data integrity protection, it may result in higher latency at the receiver than limited and partially non-malleable encryption.
By using limit malleable encryption, such as XTS-AES encryption, and partially non-malleable encryption, such as encryption with the block cipher mode of operation described above, in conjunction with a low latency authentication algorithm, such as GMC or GMAC, a low latency secure scheme appropriate for OTN networks may be provided.
Authentication algorithms may be chosen to achieve specific benefits. For example, if it is beneficial to reduce gate count, GMAC authentication may be chosen. If very simple authentication is desired, a predetermined string of characters may be used as an authentication code for partially non-malleable encryption.
Furthermore, when, for example, XTS-AES encryption is combined with GMAC authentication, computations may be simplified by transporting the initialization vector, sequence number and security parameter index at least one frame in advance of the encrypted data. This allows for pre-computation of AES for GMAC, and one AES block for XTS. Furthermore, because the same initialization vector is used for both the encryption/decryption and authentication, a packet may be efficiently constructed and transmitted.
The above description is intended by way of example only.