Hi!
I just received my ChipWhisperer-Lite, and started playing with it and worked through the first tutorial. It’s clear that this is an incredibly powerful tool, and I’m looking forward to attacking other target platforms and algorithms.
A few notes on the recently released 0.11RC1:
-
If I capture data without having specified a project, the traces go in default-data-dir. If I subsequently save the project to a directory other than the default one, the captures traces aren’t moved to the new data directory, so it appears (to the analysis tool) that traces have just disappeared into the ether. After I save the project, subsequent traces are saved to the new project data directory. Neither the quickstart video nor the attack walkthrough mention this.
-
When I try to save a project to a mapped network drive, the capture tool creates the data folders but not the CWP file. Not sure why.
-
When I try to save to a local drive, the file is created, but I get the following uncaught exception:
Failed to Open File, Exception:
[Errno 2] No such file or directory: u'D:\\Development\\Research\\chipwhisperer\\aessimple.cwp'
- When I open the monitor from general settings, I see this ( is the current number of traces):
Total Ops: <n> Total OK: 0 Total Failed: <n>
- There’s a divide by zero in the CPAProgressive script. Easy enough to fix, but may be disconcerting for new users:
Loading...Traces 0-49
D:\Development\Software\chipwhisperer\software\chipwhisperer\analyzer\attacks\CPAProgressive.py:154: RuntimeWarning: invalid value encountered in divide
diffs[key] = sumnum / np.sqrt(sumden)
Thanks for the notes! Yes there is a few bugs as you found in the SW… and the divide by zero shouldn’t affect the results, but as you say does look a little odd.
Hmm that is something I should document and/or fix… right now it requires PyCrypto to check the AES results. If pycrypto isn’t installed it just skips the check.
The CW-Lite boards shipped without the full AES programmed into the microcontroller as well. Basically doing the first couple rounds so you can perform SCA, but it avoids any possible issues regarding exporting/importing crypto. Thus even once you install PyCrypto you might get that failed message.
I’m in the process of showing how to build the target code, which includes full AES along with making your own changes. It’s completely irrelevant for the basic side-channel attacks since you recover the key in the first round or so anyway.
Ah I forgot about that… I’ve know it for so long myself that I completely forgot that can happen. I’ll update the quickstart for now until I get around to fixing that.
Thanks again for the feedback so far!
Colin,
Thanks for the quick reply, and thanks again for the ChipWhisperer-Lite. Now if only I could get my hands on a bora board… 
I just installed pycrypto using the voidspace windows installer, and verified that the monitor is now showing correct captures. I didn’t realize that WinPython doesn’t come with that as standard! With the divide by zero it seemed to me that the attack stopped whenever that happened, and didn’t recover the key. Since then I fixed the code so it doesn’t happen anymore. If I find any more issues like that I’ll set up an assembla account and send you a merge request.
Great thanks! BTW if it’s easier, I’m planning on moving the main development to GITHub soon. They fixed/improved some issues that were previously holding me back (improvements to wiki, release mechanism) from doing everything there.
So feel free to request merges on GITHub instead… however I’ll manually apply them to the Assembla branch first and let it be propagated over until I switch to GITHub as the master.
The divide-by-zero that you’re talking about is somewhat random it sounds like, I was thinking it was a consistent divide-by-zero. In that case it depends on your data capture I think, as sometimes there isn’t enough variance (or too much variance, I forget which) causing that. But yes it’s much nicer when it’s fixed 
BTW I had updated the documentation to at least call those out…
