Me and my partner are electrical engineering students, we are working on Power Analysis on RSA algorithm as our final project, and so we got Chipwhisperer Lite as research tool for our project.
I have got few question regarding on implementing an RSA algorithm on Chipwhisperer Lite and the Xmega target.
We did a few Power Analysis tests in Jupyter Notebook using the tutorials everything seems to work fine, now we want to test an RSA algorithm so we tried the [Fault_5-RSA_Fault_Attack.ipynb] notebook.
The tutorial was made for ARM target only, and to make it work on Xmega target there is a need to make changes to the RSA libraries, right now we do not have any clue how to access those libraries and what kind of necessary changes should be made to make this tutorial work on Xmega, since there is [simpleserial-rsa-xmega.c] file in the firmware folder.
Another question is, implementing RSA power analysis with Chipwhisperer lite. Is there any tutorial for example to start with, and how hard is to make RSA power analysis compared to AES power analysis.
The CWLite with the XMEGA is an older model. When the tutorials were written they were intended for the STM32. If you just want to get the tutorials working as they are, we have a product that will allow you to connect to the STM32 located here.
If you are determined to get it working for the XMEGA it should be doable. Where you will have to do some developing I’d recommend that you get the Jupyter Notebooks working outside of the virtual machine so that you can freely edit without having to work inside the virtual machine. These steps are here.
Now there is a lot of stuff already done for you from what I can tell. Change your make line in the tutorial to this:
make PLATFORM=CWLITEXMEGA CRYPTO_TARGET= AVRCRYPTOLIB CRYPTO_OPTIONS=RSA
I have tested the firmware that this builds and it does not seem to be compatible with the tutorial right out of the box. This is where the work to be done is. I’d recommend looking at the firmware for both and seeing where the difference is.
Another challenge you’ll run into is that RSA will be extremely slow on an 8-bit processor (I haven’t tried it but see this post for an idea of what to expect). A consequence of that is that with a CW-lite, you’ll only be able to capture a very small fraction of the operation.
First of all thank you all for replying, I am glad that there is a place I can ask for advice and get answers quick.
@aross Thank you for the detailed explanation. Right know me and my partner are thinking about getting the CW308 UFO board. We want to use the existing CW-LITE Capture part, is there anything else we should get? I’ll be glad to know if there is a detailed explanation to setup CW308 board to work with the CW-Lite capture board.
Thanks for the advice, so theoretically saying implementing RSA on STM32 will be faster than on the xmega?
@coflynn I am really glad to hear that and thankful for that tutorial. Right now we use version 5.1.1 using VM, do we need to get Juptyer Notebooks outside VM for version 5.1.3 to work?
Another question in general. in this example I understand that we are doing Simple Power Analysis on RSA to get part of the secret key. In theory doing different kind of PA on RSA, for exmaple CPA like the tutorials on AES (just this time on RSA instead), will it give us better results, is it possible to implement CPA or DPA on RSA with STM32 target?
Thank you all again for reading and helpful tips,
Rasik
You just need to update the “chipwhisperer” and “jupyter” submodules, rather than redownload the full VM. This will get you teh latest stuff.
On the STM32 - doing SPA on the RSA is actually trickier. Basically the implementation of RSA is done differently with mbed-TLS then with avr-crypto-lib. I do have a working demo on it but it needs a lot of clean-up (and it may not be as easily possible w/ the lite due to capturing a longer trace).
If you want to do the RSA attack with SPA I do recommend the XMEGA target as it more closely follows what you will find in other publications/examples!
First of all i want to apologize for bringing this topic up after a long time.
We decided to work with the PA_SPA_2-RSA_on_XMEGA_8bit example, which is really great! I have a couple of questions about the key size in this example:
In this example we analyze only 16 bit out of the full 16-byte key (which is 128 bit key as I understand), to make the decryption process easier. I wanted to ask if it is possible to make same analysis with the XMEGA for a bigger key size for example 512-bit key. As I understand the maximum number of samples in a single capture is around 24000 for the XMEGA, will it be possible to capture the whole power trace for bigger key size?
Another question I had, in this example the plaintext and the key are the same, I wanted to know why we need to do this for this analysis with the XMEGA, and if it is possible to make the key and plaintext not the same?
Thanks in advance, I really appreciate the support I get in this forum,
Rasik
Hi Rasik,
Some quick but incomplete answers to help you get you going:
1- Yes the cw-lite has a maximum capture size of 24k samples. However you can use the offset feature to capture a longer trace in multiple segments (i.e. set scope.adc.offset = 0 and capture the first 24k samples; then re-run using the same inputs with scope.adc.offset = 24000 to capture the next 24k samples, and so on).
2- I’m not 100% sure the reason why plaintext and key are the same, I think it’s simply because the plaintext doesn’t matter in this attack. Try editing the target firmware to use a different plaintext and you should see the attack still works. The basic principle of the attack is that it identifies whether each bit in the key is 0 or 1 based on how long it takes to process, which is a function of the key, not the plaintext.
Hello Jean-Pierre,
Thanks again for your reply, I will try as you suggested using the offset feature to capture multiple segments.
I had another question regarding the implementation of the RSA in the firmware file simpleserial-rsa-xmega.c which, as I understand, uses CRT to accelerate the decryption process, is it possible to capture those intermediate key values, dp and dq of the key?