GoalProblem statementAll Message authentication proposals require RLP reassembly before tag verification becauseThey are serialThey do not allow out of order processingThey are block level and not byte levelHMAC-SHA suffers from this.AES-CBC suffers from this.Can we have one pass encryption/decryption and integrity tag creation/verification?One movement of data from RAM to Phy and vice versa?Also good for software in allowing pre-computation for authentication also.Use some published message authentication algorithm but adapt it to LBC needs.So that security can be easily verified

ApproachWe will try to use a message integrity algorithm that allows out of order processing.Assumptions:During encryption an Application (App) packets RLP segments are sent for encryption without interleaving from other App pkt segments.No interleaving: no other App packet bits are sent until the first App pkt finishes.The only exception is re-transmission of some previously sent RLP segment of other App pkts or tunneled pkts.We focus in the following slides on the byte numbered RLP case, but can also be adapted to packet numbered RLP.

Encryption and Integrity algorithmCountermode encryptionBreak message into M1, M2, , Mn blocks each of 32 bits.Ci = Mi + (respective 32 bits of) AESk(0,cryptosync i/4)Universal hash based integrityAi are also 32 bitsA1An = AES(1,cryptosync 1)AES(1,cryptosync n/4)

P is a 32 bit prime e.g 232+15; final summation mod 232.CryptosyncOfLastByte = (last byte of RLP segment in last RLP segment of the application pkt)We first illustrate the case when RLP segments are multiple of 4 bytes (4x). We deal with the non-multiple case later.

EncryptionExample 8000th byte in flow

M1(32 bits)M2M3M4M5M6M7M8C1C2C3C4C5C6C7C8AES(0, 8000)AES(0, 8016)

C1C2C3C4C5C6C7C8AES(1, 8000)AES(1, 8016)A1A2A3A4A5A6A7A8 mod p mod 232+ mod 23232 lsb of AES(2,8028)(encryption of tag)32 bit authentication tagMessage Integrity tag creation

Hardware encryption processingFor each RLP flow Id keep a 32 bit tag accumulatorAn App pkts RLP segments reach hardware non-interleavedFirst RLP segment is encrypted and partial tag createdByte based cryptosync is used for both encryption and tag creationAis can be created as such: Given the byte sequence number, we can create AES(1,16*floor(byte number/16)) and take respective values from block. That is the byte number of first byte in block is used as cryptosync Partial 32 bit tag is created and stored in the accumulatorNon-last RLP segments are also encrypted and partial tag created.Partial 32 bit tag is added to the accumulator.Last RLP segment is also encrypted and partial tag createdPartial 32 bit tag is added to the accumulator. The tag gets encrypted.i.e. 32 bits of AES(2,LastByte) are added to the accumulator.Tag is appended to the RLP segment and sent.Tag is also sent to the CP/RAM for storage in case of RLP retransmission.Only for the final RLP segment of an App pkt is the tag sent to RAMThe tag could be written by hardware in to a small buffer which has the last RLP segments byte number and the 32 bit tag. The CP can periodically read the buffer so there is no waiting for access to PC bus.

Hardware encryption - RetransmissionWhen the CP sends a RLP fragment to the hardware, it also sends a bit (not sent over the air) to indicate if something is a retransmission or not.Retransmitted segments are encrypted again, but the partial tag is not created again and not added to a tag accumulator.This is because the tag calculation has already taken place for that App pkt.For retransmission of the last RLP segment of an App pkt.Segment is encrypted.CP sends the authentication tag for the pkt since it was already calculated and stored in RAM previously.

Hardware decryptionFor each (non-last) RLP segment received Create a 32 bit partial tag and decrypt the segmentSend both the segment and the tag to RAMThe tag could be added to the RLP header or added to the tail.For last segment received.create the 32 bits partial tag with adding of AES(2,cryptosyncOfLastByte) to the partial tag.Add and subtracts on this slide are mod 232.Subtract the received tag from the partial tag above.Decrypt the segmentSend both the segment and the tag to RAMCP When CP assembles the App pkt, it also adds the partial tags from all the segments together.If the tag summation == 0 then accept pkt else reject pkt.That is if all the summation of the calculated partial tags equals the received tag then tag is verified.

Computational EfficiencyCP involvement is kept to a bare minimumAs RLP headers have to be processed anyway.One more field is added to RLP header sent to RAM during decryption.During encrytion, the CP has to receive the tag back from the hardware or read it from a small buffer in hardware.This flexible out of order procession has only a small overhead.2 AES calls are needed per 128 bits, just like other modes, eg. Counter mode encryption + CBC MAC.A 32 bit multiply is needed per 32 bits. Next we deal with non multiple of 4 byte (4x) case.

RLP segments non-multiple of 32 bitsGiven a byte sequence number, one can identify the beginning byte that is a multiple of 4 bytes.From that point can use the universal hash on each 4 byte (32 bit) value. Need to still handle the beginning bytes that are before the multiple of 4 byte boundary. Also need to do this for ending bytes of the segment.Beginning bytes of non-first RLP segmentThe 32 bit ciphertext Ci can be written as Ci,a224+Ci,b216+Ci,c28+Ci,d20So CiAi mod p can be rewritten as AiCi,a224+AiCi,b216+AiCi,c28+ AiCi,d20mod pExample RLP 1 ends with 3 bytes extra after the last 4 byte multiple; the next RLP segment (RLP 2) has the remaining byte before the 4 byte multiple begins.Partial tag of RLP1 has added AiCi,a224+AiCi,b216+AiCi,c28 mod p Partial tag of RLP 2 has added Ai*Ci,d mod p Figure in next slide illustrates this.

Application packet Example RLP stream begins at byte number 8000RLP 1HeaderRLP 2HeaderRLP segement 1(7 bytes) RLP segement 2(5 bytes)RLP 1HeaderRLP 2HeaderRLP segement 1

RLP segement 2

Encrypt Encrypt C1,aC1,bC1,cC1,dC2,aC2,bC2,cC2,dC3,aC3,bC3,cC3,c32 bit Ci are Made up of 4 Bytes Ci,a Ci,b Ci,c and Ci,d. C2 has its first 3 bytes as part of RLP segment 1 and the last byte as part of RLP segment 2.Similarly 32 bit pseudorandom bits Ai can be broken into bytes Ai,a Ai,b, Ai,c, and Ai,d. A2s first 3 bytes will be used to integrity protect RLP segment 1 and the 4th byte will be for RLP segment 2.Segment sizes of 7 and 5 bytes are for example purposes only.. . .RLP NAES(1,8000)

A1,aA1,bA1,cA1,d

A2,aA2,bA2,cA2,dA3,aA3,bA3,cA3,cAES(1,8000)Partial tag RLP 1 = A1C1 + A2C2,a 224+A2C2,b216+A2C2,c28 mod pPartial tag RLP 1 = A2C2,d20 + A3C3 mod pExample of partial tag calculation for non-multiple of 32 bits RLP segments

Variable length App PacketStandard techniques like padding can be used to handle variable length packets. Details need to be specified.Last part of last RLP segment in App packet needs to be treated specially.Padding option:Last byte as cryptosync option:However, the above padding option is not necessary if we are using the last byte of the App packet as cryptosync: AES(2,lastByte).Thus App packets of differing length will end in different byte number and the encryption of the tags will be different. Two messages may create the same tag, for example a 4x byte length message M and the message M followed by a byte of 0. However, each will be encrypted differently, that is a different random string will be added for each message and security will be preserved.Beginning byte of the packet also needs to provide AES input. Details to be specified.

Beginning and end of App packetsPreviously we dealt with RLP segments beginning and ending at non-multiple of 4 bytes (4x), but belonging to the same App packet.We reused Ai at the ending bytes of a RLP segment and also at the beginning bytes of the next RLP segment.Since the message authentication algorithm required it.App pkt that end at non-multiples(4x) and the next App pkt that begin at non-multiples of 4 bytesWe dont want to reuse the Ai for both App pkts (end of one and beginning of another) otherwise security may be harder to see.For beginning bytes of App pkt we will continue the use 4 byte Ai based on current i, i.e. i equal to floor(beginning byte/4).For ending bytes,4x+1 or 4x+2 or 4x+3 byte, we will use 1 to 3 leftover bytes of AES(2,lastbyte) output since only the first 4 bytes of output are used for tag encryption.

OptionsCan use 64 bits tags.Added computation.Multiplication can be over 32 bit Galois FieldDetails for dealing with variable size needs to be specified.Methods to minimize the number of AES calls exist in the literature But requires tree hash, larger key sizes, more complex.

Security (I)Universal hash plus one time pad is a secure message authentication algorithm.Proposed and proved in Wegman and Carter, New hash functions and their use in authentication and set equality, 1980Multiplicative hash as universal hashProposed in carter and wegman Universal classes of hash function, 1979.Clear statement and proof of it as a delta-universal hash in Theorem 2 in Halevi and Krawczyk, MMH: software message authentication in the Gbit/second rates 1996.We are using the above universal hash so security proofs directly applyWe only need to deal with our variations for handling variable lengths and non-multiple of 4 byte boundaries.Our security may be stronger in the sense that we use a different hash key for each message whereas the same hash key would have been sufficient according to above.

Packet number based RLP flows.Cryptosync for encryption is packet number concatenated by a subcounter which changes for each 128 bit block. i.e. AES(0,pkt#,subcounter)The same packet number is used for the entire App packet with only the subcounter changing.We reuse AES(1,pkt#,subcounter) for creating Ai for message authentication.For tag encryption, we would use AES(2,pkt#,subcounter, byte number) where byte number is 1 to 16 depending on the last byte number.The rest is the same as with byte numbered RLP.