Hello,
I have a problem when I try to compile a simpleserial-aes.hex.
I found that there are some other algorithm like masked aes256 in DPAv4,
but I failed to compile a hex file using this algorithm instead of simpleserial-aes128
So I want to ask about how should I do to write a simpleserial-aes256 version into ATMega328p?
Thanks for your help.
Best Regard,
Andersen You.
Hi Andersen,
With AES-256 the only requirement would be a longer (32-byte) key… what specific errors were you seeing?
As a first step I would make the system accept a 16-byte key, and simply set the last 16 bytes to a known (and fixed) value. This would mean there are no changes required anywhere.
Regards,
-Colin
Hello,
Since I wanted to build the dpav4 as-256 into ATMega328p,
I modified the makefile in hardware\victims\firmware\simpleserial-aes
by two places:
After these changes I tried to compile,
and then it showed this error message:
make: *** No rule to make target ‘simple serial-aes.elf’, needed by ‘elf’. Stop.
So would I still need to modify something else?
Thanks for your help.
Best Regards,
Andersen You.
That error normally means it didn’t find files. The makefile changed slightly and that section wasn’t uplodated, you’ll need to first replace those lines you uncommented with:
########
#From http://www.dpacontest.org/v4/rsm_doc.php which is a masked version
#of AES-256. You must copy source files into ../crypto/dpav4/ directory yourself
CRYPTO_LIB = dpav4
SRC += aes_enc.c aes_keyschedule.c
ASRC += gf256mul.S aes_sbox-asm.S
CDEFS += -DDPAV4 -D"hal_trig1(a)" -D"hal_trig0(a)"
VPATH += :../crypto/$(CRYPTO_LIB)
EXTRAINCDIRS += ../crypto/$(CRYPTO_LIB)Then you need to copy all the dpav4 source code (from dpacontest.org/v4/data/rsm/s … v4_rsm.zip) into the crypto/dpav4 directory (you’ll need to make the dpav4 directory first).
Delete/rename ‘hal.h’ and ‘hal.c’ from the dpav4 directory (as the name conflicts with usage elsewhere).
It should now at least build! I haven’t checked to see if it works yet…
-Colin
Hello Colin,
thanks for your help!
However, I still cannot successfully build the hex file.
It seems there are something wrong when compiling the file …/crypto/dpav4/aes_enc.c.
The following lines are the error messages:
In file included from …/crypto/dpav4/aes_enc.c:15:
…/crypto/dpav4/t0.h:82: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘t0_testP1P2’
…/crypto/dpav4/t0.h:93: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘attribute’ before ‘t0_testP3’
…/crypto/dpav4/aes_enc.c: In function ‘aes_encrypt_core’:
…/crypto/dpav4/aes_enc.c:134: warning: statement with no effect
…/crypto/dpav4/aes_enc.c:151: warning: statement with no effect
make: *** [objdir/aes_enc.o] Error 1
I already checked the file ‘t0.h’, but it wasn’t like something missed.
On other websites some people think it were caused by misusing of the compiler.
So, what is your opinion about this error?
Thanks for your help again.
Best Regards,
Andersen You.
Hmm… actually I’m not too sure what happened there. What version of avr-gcc do you have (check with “avr-gcc -v”)?
This worked OK for me with gcc version 4.3.3. I had only just downloaded the source files & tested, so there shouldn’t be any sort of difference between our two files!
Looking at the sources, actually I think the issue might be that your version doesn’t support ‘bool’ in either avr-libc or avr-gcc. However none of those functions are actually used (the t0_xxx are the communications functions). I’d suggest simply modifying the source file by either commenting out that prototype/file or changing “bool” to “int” and see if it compiles.
I’ll try to check here if it does actually work…
Regards,
-Colin
Hi, Colin,
thanks for your assistance.
Now it works.
Best Regards,
Andersen You.
Hi Colin,
Now I have another problem that since the aes-256 of dpav4 is a masked version,
it is too hard for me to break it now.
So could I modify it into a non-masked version?
Or would you know how to build a non-masked aes-256 into ATMega328p?
And I still have another question that where does the CWCapture save the plaintext and cipher text?
Thanks for your help.
Best Regards,
Andersen You.
Hello,
And it does indeed save the plaintext & ciphertext, all of it saved into a directory “somewhere”. This is defined in the “.cwp” project file - you can open that file to see where the directory is. It will have a reference like “cwlite_XMEGAhw_data\traces\config_2014.12.21-17.51.45_.cfg”. This tells you the directory, and there will be a bunch of files with the same prefix (for example starting 2014.12.21-17.51.45_) which have the ‘trace’, ‘textin’, ‘textout’ (and key).
HTH!
-Colin
Hi Colin,
The tutorial is really helpful, and now I try to modify it into an AES-256 enc-version.
However, when I traced the code in appendix C (AES-256 13th Round Key Script),
I didn’t understand some lines of this code, which are:
def initPreprocessing(self):
self.preProcessingResyncSAD0 = preprocessing.ResyncSAD.ResyncSAD(self.parent)
self.preProcessingResyncSAD0.setEnabled(True)
self.preProcessingResyncSAD0.setReference(rtraceno=0, refpoints=(9063,9177), inputwindow=(9010,9180))
self.preProcessingList = [self.preProcessingResyncSAD0,]
return self.preProcessingList
What do these lines do and why don’t we need when we analyze the 14th round key?
(Hmm, maybe it needs, but the same place in 14th script is quite simple, where the list is left blank.)
Thanks for your help.
Best Regards,
Andersen.
Hi Andersen,
Those “resync” scripts are needed because there is some additional jitter when reaching further into the loop. The jitter is because there is actually a timing leakage in the AES implementation (this comes about from the xtime normally).
If you don’t synchronize the leakage doesn’t always line up, and you get worse performance. You don’t need them to recover the 14th round as there is no jitter, it’s only the 13th round that gets affected [NB: we are talking about ‘encryption’ rounds, so the 14th round is actually the first one processed on decryption, and 13th is the next]. The numbering of the rounds might be confusing there too…
-Colin
Hi Colin,
First thanks for your reply and sorry for bothering you again.
So in this line,
self.preProcessingResyncSAD0.setReference(rtraceno=0, refpoints=(9063,9177), inputwindow=(9010,9180))
How are the meaning of these variables: rtraceno, refpoints, and inputwindow.
I think that maybe “inputwindow” is the guessed area that leakage with jitter?
Thanks for your help again.
Best Regards,
Andersen.
Hi Anderson,
“rtraceno” is the “reference” trace. This is used to define the pattern the system is trying to find in all other traces. In this case it means the reference pattern is between points 9063-9177 of trace 0. Ideally there should be some unique pattern there.
The “inputwindow” tells the system to then search in every following trace for that pattern, looking only between points 9010-9180. It’s helpful to limit the search space as otherwise it might lock onto an earlier instance of a similar pattern, and is also faster as it does less computation.
If the pattern is found in that area, it will shift the searched trace to match the “reference trace”.
Regards,
Hi Colin,
Thanks a lot and I want to tell you that I have successfully broken AES 256 using CPA=)
Regards,
Andersen.