PKA Modular Exponentiation not working as expected

[PKryg.1]

Hello,

I'm trying to figure out how to properly use STM32WB55 PKA registers for RSA key generation and encryption/decryption. I have chosen small (63 bit) primes for generating RSA private key, which worked perfectly. However, I am having trouble with encryption. As far as I understand, simple encryption/decryption for RSA is just modular exponentiation using message as a base, public exponent for encryption, private for decryption and a modulus. However, I have wrong result for encryption and can't figure out what I do wrong.

Here is pseudocode, how I set up the process:

uint32_t message [] = [0x656C6C6F, 0xDD810048, 0x6D1F8EDA, 0x12327939];
uint32_t public_exp [] = [0x00010001, 0, 0, 0]; // 65537
uint32_t modulus [] = [0x1b8abb91, 0xe2c25d78, 0x5f41a975, 0x90275365]; // Calculated from primes
PKA->enable();
PKA->set_mode(MontgomeryParameterComputationThenModularExponentiation);
PKA->ram(0x400).write(32); // Exponent length, tried changing it already, many times
PKA->ram(0x404).write(32*4); // Operand and modulus length in bits
PKA->ram(0xA44).write(message);
// Write empty word after data
PKA->ram(0xBD0).write(public_exp);
// Write empty word after data
PKA->ram(0xD5C).write(modulus);
// Write empty word after data

PKA->start();
// Wait for finish
...
uint32_t buff[4];
PKA->ram(0x724).read(buff);

 However, the result I get is wrong. I am getting an array of values:
[0x128b8968, 0xb14ac363, 0xf4179c8f, 0x149e3d10
Which can be translated to value 0x149e3d10f4179c8fb14ac363128b8968. Which is wrong. I manually calculated to correct result of such computation (and also used internet provided calculators as well as created simple python script to prove it) and it should be:
0xa1faaa802c5ec9bc3b254a9bf58c2a9

Also, using private exponent to decrypt given ciphertext doesn't give me original message, so clearly I'm doing something wrong, but just can't figure it out.

[PKryg.1 · Accepted solution]

Fixed this, there was a problem with the board itself. It works on another board, same model. HW issue.

[980nm]

Hi, could you please elaborate on what the exact hardware issue was? I'm noticing similar issues when trying to use the PKA myself, so I'm wondering if I'm seeing the same sort of effects here.

[PKryg.1]

It's hard to say, but I think a part of RAM responsible for accepting operand was faulty and always set to 0. I noticed this when I was setting exponent to different values and the only moment, when result was anything other than 0 was when exponent was 0 (0^0 = 1, according to PKA). The values I was before in the result was just a residue after other operations I performed on the PKA.

If this is not a hardware issue, here is couple of steps you can follow in case you have a problem with PKA

1. Make sure you are writing values under correct addressess in RAM. In documentation some operand A and B are called that in many modes of operations, but the address is different.

2. Makes sure operand length is the same as modulus length. If you have operand smaller the the modulus, prepend it with 0x0 words.

3. After each value written to RAM (other than expected 32 bit values, like operand length or operation) you whould write 0x0 word to RAM.

4. Make sure you are writting data in correct order. PKA expects words in LSB order. So, If you have, i.e. value
0xAAAAAAAABBBBBBBB
it must be written to RAM like this:
[0xBBBBBBB 0xAAAAAAAA]
This is actually pretty useful, since when you are prepending operand value with 0's, the actual value will be at the begging and PKA won't read 0's words as a end of operads.

5. Pick primes carefully. PKA doesn't like values, that have a word filled with 0's in the middle. Like this one:

0xAAAAAAAA00000000BBBBBBBB

[980nm]

hm, I checked and double-checked all of those (and even rewrote my code to use the PKA HAL lib instead of the LL access) and the results I'm getting are still nonsense.

Could it be that the PKA has stringent power supply requirements? I'm currently more or less breadboarding it at the current design stage so the current situation is a bit non-ideal (it's all jumper cables etc). The values in the PKA row of the "peripheral current consumption" table in the datasheet (table 82, page 210 in DS12736 rev 4) look impossibly low (less than a single timer or even an AHB/APB bridge) so they feel wrong but I'm not sure if that's the case here.

[PKryg.1]

It might be. It would be good if you could find a dev board somewhere (simple Nucleo board with STM32WB55 on board is enough), power it over STLink and see if the issue persists. Low power for PKA seems like a valid reason for dumb resposnes from the peripheral.