Looking up information about 5G and the previous 3GPP standards, why have they been incorporating non-conventional algorithms into the standards? For example, AES has been considered secure for ages and there is lots of support for hardware acceleration, but what was the rationale behind, for example, adding ZUC and SNOW 3G too? Does adding more algorithms make it easier for network operators in any way?
$\begingroup$
$\endgroup$
0
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
6
These decisions are driven by silicon. Most specifications for hardware are built around a minimally viable CMOS implementation (ex: MPEG-1, lightweight cryptography via NIST 8114). This is particularly true in commodity parts, such as cell phones.
When you make wireless ICs, you have two clocks in the system at a minimum, which are the carrier frequency and then the baseband frequency. As an example, for the 900MHz RFID tags that are used for inventory control, you have a 900MHz frequency and then a 1MHz-ish clock (programmable) that handles bit stream generation to give you about 100kbs of throughput. When I make RFID tags, I use a feistel cipher in a bit serial mode because I can use the carrier clock run the cipher in a way that I do not have to wait for data to be ready. By the time that the slow data has been encrypted, it's ready to send.
In the case of AES, I need to fill 128-bits into the register, and then add a buffer to hold the result. You need to do this with the feistel ciphers as well, but AES is rather large in silicon and slow compared most feistel ciphers in this specific context. Not using AES allows me to use less silicon, which then helps keep costs down.
update: Looking at my GDS files for layout and simulations on an ancient process (GF 180nm), SIMON 128/256 was 30% of the area and 50% of the power compared to AES256 for an RFID tag. The sboxs were not done with a lookup table, but explicitly calculated in circuits. A note, I do not believe that this would scale well due to metals at sub-14nm nodes (sadly, my lectures from Georgia Tech are all no longer online, as I spent a week on this. Stanford has some lithography notes. I'm still looking for a good public facing document). I would expect the feistel to be a little larger, but AES to scale the same due to colored metals; however, the power should be similar. (I cannot share specific details on modern processes.)
-
3
-
7$\begingroup$ @kelalaka This relates of the lithography requirements for metals at nodes <45nm. There's a picture from one of my layouts in this answer: electronics.stackexchange.com/questions/211868/… $\endgroup$– b degnanCommented Jun 6, 2020 at 19:37
-
$\begingroup$ Is there really a 900 MHz clock for much logic in a 900 MHz RFID tag? That seems fast, thus power-hungry. In the affirmative, what does this 900 MHz drive beyond one frequency divider (D gate or so) to make it 450 MHz? $\endgroup$– fgrieu ♦Commented Jun 25, 2020 at 13:59
-
$\begingroup$ @fgrieu The 900MHz clock is derived from the carrier. It's a bit of a misnomer because the tags operate from 820MHz to 940MHz due to different countries having different rules. For me, I use the carrier clock to run the SIMON input clock after the data has been loaded into the registers at a slow 100KHz. Let me see if I can find a picture to add. $\endgroup$– b degnanCommented Jun 25, 2020 at 14:25
-
1$\begingroup$ @fgrieu No part of the tag needs to run at the carrier frequency; however, it's the "free" fast clock source for cryptography. (RFID tags for inventory here: gs1.org/standards/epc-rfid/uhf-air-interface-protocol). The challenge is getting them to work everywhere in the world. You'll notice that a cryptographic framework exists, but nothing is actually implemented in the spec as they passed the buck. Generally, if you are using backscatter, you use the carrier clock to run the symmetric cipher, otherwise, it's your fast clock because that way data encryption is fast. $\endgroup$– b degnanCommented Jun 25, 2020 at 16:48