Developing analyzer for different cryptographic models

Hello Colin and others,

As I read from this paper - section 5.2, Chipwhisperer is absolutely flexible with cryptographic methods other than AES because of its powerful modular design. I would like to know if anyone has implemented other methods such as RSA or 3DES and if so, make it public. If not I would like to implement both methods and in case everything went right, push it to the repository(of course if Colin approves).
I would be glad to see if you know a starting point for doing so or have some workarounds or insights. I guess there would be some difficulties because of different key sizes in different methods.

Regards

Hello,

I’ve started to think about adding a 3DES module - right there there are indeed issues with a few fixed key sizes in the system that need to be addressed. But there isn’t a lot regarding documentation as a starting point, if you have specific questions let me know.

And of course I welcome contributions back into the main repo :slight_smile: That’s the idea of it being open-source!

There was at one point someone working on a DES module, but I’m not sure if that went anywhere. It was with a much older version of the SW though so I doubt would work with the newer framework.

Regards,

-Colin

Hello Colin,

Sorry for writing this post in software forum… Actually I’m stuck in the idea of working on other cryptographic models. My sasebo-w board’s smart card is programmed with a file named “AES.hex”. As the documentation says, there exists a smart card OS which handles AES, DES and RSA at the same time. But my smart card is only programmed for AES. I tried hard googling but couldn’t find any c project related to sasebo-w smart card OS.
Could you please tell me if there exists a source similar to the behavior of sasebo-w smart card OS APDU commands?

Regards

Hello,

No problem putting it here - I’m hoping the forum is used for all sorts of general talk about research projects! Anyway to answer your question:

I don’t know of this in source form. I thought the “Card OS” for SASEBO-W included the other features but I haven’t checked myself (only based on satoh.cs.uec.ac.jp/SASEBO/en/board/sasebo-w.html), but it’s just a binary.

-Colin

Hello Colin,
Happy new year :slight_smile: Hope you’re doing well,

Yes I’m pretty confused there’s no source file for SASEBO-W cardos and even the hex files are named AES.hex and cardos_aes_2012_0703.hex . There seemes to be no support for DES nor RSA as said in the document in action! The diff result for both files showed they’re identical. I changed the provided C# of sasebo-w checker to work with DES but the result of sending DES and RSA APDUs responded with BAD INS code.

With the provided reasons I decided to useDPA Contest V4 and add DES algorithm to it later. As CW also supports this protocol, I decided to ask you about programming SASEBO-W with this protocol. Actually I programmed the smartcard with the provided hex file and the output of avrdude was as expected in the readme file. There exists a test file named smartcardV41.py in the demo directory of the archive file downloaded from the website. The problem is that the response from this script is empty. Also I programmed the FPGA with the provided bit file and the result did not change.

I’m asking if you have a clue what’s wrong? Did it go all right when you tested this protocol?

Regards

Hello,

The DPA Contest v4 card isn’t a great starting point… the problem is it doesn’t respond properly (does not echo an ACK), and it can trip up certain readers. What harware are you using? It’s possible to get it working with the ChipWhisperer but depends on your hardware.

You can also fix the error… basically need to echo back the INS byte. I think I’ve got such a fixed framework, need to look through my example code…

Hello Colin,

I’m using SASEBO-W with picoscope.
Actually I programmed the flash with CW’s mcs file and programmed the FTDI for both ports A and B to be in FIFO mode. When using CW’s capture software and loading the example project, it connects successfully. But when I change the protocol to DPA, it throws this error:

Traceback (most recent call last): File "C:\chipwhisperer-0.12RC1\software\chipwhisperer\capture\ChipWhispererCapture.py", line 797, in capture1 ac.doSingleReading() File "c:\chipwhisperer-0.12rc1\software\chipwhisperer\capture\AcquisitionController.py", line 141, in doSingleReading self.textout = self.TargetDoTrace(self.textin, key=None) File "c:\chipwhisperer-0.12rc1\software\chipwhisperer\capture\AcquisitionController.py", line 91, in TargetDoTrace self.target.go() File "c:\chipwhisperer-0.12rc1\software\chipwhisperer\capture\targets\SmartCard.py", line 965, in go self.protocol.go() File "c:\chipwhisperer-0.12rc1\software\chipwhisperer\capture\targets\SmartCard.py", line 789, in go self.hw.ser.flush() AttributeError: 'ReaderChipWhispererSCard' object has no attribute 'ser'

I think the dpa protocol is only implemented for “Chipwhisperer-ser” reader hardware. And when choosing Chipwhisperer-ser , this error is thrown:

Traceback (most recent call last): File "C:\chipwhisperer-0.12RC1\software\chipwhisperer\capture\ChipWhispererCapture.py", line 739, in doConDisTarget self.target.con() File "C:\chipwhisperer-0.12RC1\software\chipwhisperer\capture\ChipWhispererCapture.py", line 198, in con self.driver.con() File "c:\chipwhisperer-0.12rc1\software\chipwhisperer\capture\targets\SmartCard.py", line 931, in con self.driver.con(self.oa) File "c:\chipwhisperer-0.12rc1\software\chipwhisperer\capture\targets\SmartCard.py", line 365, in con self.ser.con() File "c:\chipwhisperer-0.12rc1\software\chipwhisperer\capture\targets\SimpleSerial.py", line 339, in con self.checkVersion() File "c:\chipwhisperer-0.12rc1\software\chipwhisperer\capture\targets\SimpleSerial.py", line 205, in checkVersion data = self.oa.sendMessage(self.CODE_READ, self.ADDR_BAUD, maxResp=4) AttributeError: 'NoneType' object has no attribute 'sendMessage'

Anyway, if you have a suitable framework, I would be so glad if you help me that way…

Thanks a lot

The DPAv4.1/.2 card doesn’t work with the SASEBO-W. That’s a limitation of the lack of ACK byte, it will always fail out.

You’re actually better off using the SASEBO-W with the original SASEBO-W bitstream, and then using the “System Serial (SASEBO-W)” reader. I haven’t tried it with the DPA Contest v4.2 card, but it’s the most likely to work. But the better answer is to use a proper framework, still got to see where I had those files…

Hello Collin and fellow members,

Few months back it was mentioned you might be implementing a 3DES module, has there been any update, or if any one has a 3DES module.

Any help with this 3DES

Regards :smiley:

Hello Zain,

We were busy implementing a framework for smart card because we wanted to add 3DES and RSA support to smart card. Fortunately it’s finished and we implemented the source for AES, DES, 3DES and RSA with dpa contest framework. Actually the protocol for capture module in CW depends on the implementation of smart card for that cryptographic model. We added a very simple protocol to CW capture to work with but as our smartcard protocol is not something standard and well known I did not request a pull in github repo.
Unfortunately we’ve not done anything special in attacking. If we made a module for 3DES or RSA models in CW’s analyzer I will contribute to github repo.
I wish other members has something more to offer.

Regards

Hello,

Do you have a link to the repo? Even if it’s “not well known”, if it’s publicly available I’d be happy to add this.

Or at least a link somewhere so people can find it, as it sounds like a very useful resource for the community.

Thanks!

-Colin

About using ChipWhisperer Lite with DES, I made a new firmware image for the XMEGA target on the ChipWhisperer Lite. I used the SimpleSerial-Base as my starting point, and compiled it with the DES code from avrcryptolib. Below is the code. I captured some traces, and the CWAnalyzer.pyw insists on trying to recover an AES key, not DES or something else. Furthermore, it complains about encountering NaN’s when showing the probability of any byte in the key sequence. So how would I go about using DES with CWLite, and is my code below correct? The code does compile, and I was able to push the resulting .hex file to the board. When I capture traces against it, the power usage graph is much different from the AES graph. I just want to make sure issues with the different key size are handled properly, and that the CWAnalyzer.pyw is able to still work.

/*
    This file is part of the ChipWhisperer Example Targets
    Copyright (C) 2012-2015 NewAE Technology Inc.

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.
*/

#include "hal.h"
#include <stdint.h>
#include <stdlib.h>

#include "des.h"

#define IDLE 0
#define KEY 1
#define PLAIN 2

char hex_lookup[16] = {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'A', 'B', 'C', 'D', 'E', 'F'};

uint8_t* hex_decode(const char *in, int len,uint8_t *out)
{
        unsigned int i, t, hn, ln;

        for (t = 0,i = 0; i < len; i+=2,++t) {

                hn = in[i] > '9' ? (in[i]|32) - 'a' + 10 : in[i] - '0';
                ln = in[i+1] > '9' ? (in[i+1]|32) - 'a' + 10 : in[i+1] - '0';
                out[t] = (hn << 4 ) | ln;
        }

        return out;
}

void hex_print(const uint8_t * in, int len, char *out)
{
		unsigned int i,j;
		j=0;
		for (i=0; i < len; i++) {
			out[j++] = hex_lookup[in[i] >> 4];
			out[j++] = hex_lookup[in[i] & 0x0F];			
		}
		
		out[j] = 0;
}

#define BUFLEN 64

uint8_t memory[BUFLEN];
uint8_t tmp[BUFLEN];
uint8_t ctxt[16];
char asciibuf[BUFLEN];
uint8_t pt[16];

int main
	(
	void
	)
	{
    platform_init();
	init_uart();	
	trigger_setup();
	
 	/* Uncomment this to get a HELLO message for debug */
	/*
	putch('h');
	putch('e');
	putch('l');
	putch('l');
	putch('o');
	putch('\n');
	*/
			
	/* Super-Crappy Protocol works like this:
	
	Send kKEY
	Send pPLAINTEXT
	*** Encryption Occurs ***
	receive rRESPONSE
	
	e.g.:
	
    kE8E9EAEBEDEEEFF0F2F3F4F5F7F8F9FA\n
	p014BAF2278A69D331D5180103643E99A\n
	r6743C3D1519AB4F2CD9A78AB09A511BD\n
    */
		
	char c;
	int ptr = 0;
    
	char state = 0;
	 
	while(1){
	
		c = getch();
		
		if (c == 'x') {
			ptr = 0;
			state = IDLE;
			continue;		
		}
		
		if (c == 'k') {
			ptr = 0;
			state = KEY;			
			continue;
		}
		
		else if (c == 'p') {
			ptr = 0;
			state = PLAIN;
			continue;
		}
		
		
		else if (state == KEY) {
			if ((c == '\n') || (c == '\r')) {
				asciibuf[ptr] = 0;
				hex_decode(asciibuf, ptr, tmp);
				
                /* KEY LOAD WOULD GO HERE */
                
				state = IDLE;
			} else {
				asciibuf[ptr++] = c;
			}
		}
		
		else if (state == PLAIN) {
			if ((c == '\n') || (c == '\r')) {
				asciibuf[ptr] = 0;
				hex_decode(asciibuf, ptr, pt);

				/**********************************
                 * Start user-specific code here. */			
				trigger_high();

				des_enc(ctxt, pt, tmp);
				
                //16 hex bytes held in 'pt' were sent
                //from the computer. Store your response
                //back into 'pt', which will send 16 bytes
                //back to computer. Can ignore of course if
                //not needed
                
				trigger_low();
                /* End user-specific code here. *
                 ********************************/
				               
				/* Print Results */
				hex_print(ctxt, 16, asciibuf);
				
				putch('r');
				for(int i = 0; i < 32; i++){
					putch(asciibuf[i]);
				}
				putch('\n');
				
				state = IDLE;
			} else {
                if (ptr >= BUFLEN){
                    state = IDLE;
                } else {
                    asciibuf[ptr++] = c;
                }
			}
		}
	}
		
	return 1;
	}

Attached is an image showing the raw inputs and outputs to the Atmel test device after I had flashed it with the DES code I had posted before. However, ChipWisperer does the returning cypertext as None, and the key is padded to the AES size, not the key I specified, yet the plaintext stays small. Any thoughts?

Thank you Richard555 for the contribution!
Last week we developed DES firmwares to our supported target hardwares and extended our CWAnalyzer tool to support DES attacks. We are still fixing some issues, but the algorithm is already capable of recovering 48 bits in a total of 56 (the other 8 bits to complete 64 are parity bits). The 8 unknown bits can be easily recovered using brute force (only 256 combinations).

This implementation is being pushed to the new_attack branch and will be merged to master soon.

I just noticed the DES support in the code on Github, thank you! I had already hacked something together to get DES traces. Thanks for your support of the project.