FICHSA ChipWhisperer Tutorial Requirements

At the FICHSA Conference (
https://fichsa.sise.bgu.ac.il ) I will be running a short workshop on ChipWhisperer using the ChipWhisperer-Nano.

A direct link to a Google Doc with the most up to date information is available here: https://docs.google.com/document/d/1IgDeGZ6d0FEYJbaF4a-KsBhdIHlMZg04-wQYUSZgnks/edit?usp=sharing

If you want to fully play along, please bring a laptop with the following installed and setup:

  1. VirtualBox 5.x (5.2.28 is latest supported). You CANNOT use VirtualBox 6 due to some unknown incompatibility.
  2. VirtualBox Extension pack for version you installed (direct link to 5.2.28, does not depend on the host OS).

I will be (hopefully) posting a VirtualBox image once one is fully updated.

If you don’t need hardware and still want to see how the system works, please have a Google account – some of the work can be done on Google Colab.

See the Google Doc link above for more updated details (more detailed install / setup instructions etc)

Glitching Trezor using EMFI Through The Enclosure

As mentioned on the Trezor blog post, their latest security patch fixes a flaw I disclosed to them in Jan 2019. This flaw meant an attacker with physical access to the wallet can find the recovery seed stored in FLASH, and leave no evidence of tampering.

This work was heavily inspired by the wallet.fail disclosure – I’m directly dumping FLASH instead of forcing the flash erase then dumping from SRAM, so the results are the same but with a different path. It also has the same limitations – if you used a password protected recovery seed you can’t dump that.

Practically, it has the advantage of not requiring you to modify/tamper with the enclosure at all either to do the fault injection or read data off . Wallet.fail uses the physical JTAG connection, whereas I’m using the USB connection. But by comparison the wallet.fail attack is more robust and easier to apply – my EMFI attack can be fiddly to setup, and there is some inherent timing jitter due to the USB stack processing. Without further effort to speed up my attack, it’s likely the process of opening the enclosure & applying the wallet.fail method would be a faster in practice.

Please do not contact me if you have a “forgotten password” or something similar with your Trezor. I’m not willing to perform this work under any circumstances.

Summary

USB requests that read from memory (such as a USB descriptor read) accept a maximum packet size that is MIN(requested_size, size_of_data_structure). The code as written defaults to accepting the requested size, and overwriting it with a smaller “valid” value.

Using fault injection (here demo’d with EMFI), this check can be skipped. The device will accept up to 0xFFFF as a size argument, giving an attacker access to read large chunks of either SRAM or FLASH (depending where the descriptor is stored).

Due to the FLASH memory layout, the sensitive metadata lies roughly AFTER the descriptors stored in bootloader flash space. Thus an attacker can read out the metadata structure from memory (seed etc). Notably this does not require one to open the enclosure due to use of EMFI.

Using voltage glitching would almost certainly work as well, but likely requires opening the enclosure making tampering more evident (possibly it would work via USB +5V input even which wouldn’t require opening the enclosure).

Details

I’ve chosen to demo this with WinUSB descriptor requests, as they have a very simple structure. In addition the WinUSB has one descriptor in FLASH and one in SRAM, giving you the ability to chose which memory segment to dump. Other USB requests should work too, but I haven’t tested them.

Consider the following function, where the critical calls are the len = MIN(len,…) calls (two of them can be found):

static int winusb_control_vendor_request(usbd_device *usbd_dev,
					struct usb_setup_data *req,
					uint8_t **buf, uint16_t *len,
					usbd_control_complete_callback* complete) {
	(void)complete;
	(void)usbd_dev;

	if (req->bRequest != WINUSB_MS_VENDOR_CODE) {
		return USBD_REQ_NEXT_CALLBACK;
	}

	int status = USBD_REQ_NOTSUPP;
	if (((req->bmRequestType & USB_REQ_TYPE_RECIPIENT) == USB_REQ_TYPE_DEVICE) &&
		(req->wIndex == WINUSB_REQ_GET_COMPATIBLE_ID_FEATURE_DESCRIPTOR)) {
		*buf = (uint8_t*)(&winusb_wcid);
		*len = MIN(*len, winusb_wcid.header.dwLength);
		status = USBD_REQ_HANDLED;

	} else if (((req->bmRequestType & USB_REQ_TYPE_RECIPIENT) == USB_REQ_TYPE_INTERFACE) &&
		(req->wIndex == WINUSB_REQ_GET_EXTENDED_PROPERTIES_OS_FEATURE_DESCRIPTOR) &&
		(usb_descriptor_index(req->wValue) == winusb_wcid.functions[0].bInterfaceNumber)) {

		*buf = (uint8_t*)(&guid);
		*len = MIN(*len, guid.header.dwLength);
		status = USBD_REQ_HANDLED;

	} else {
		status = USBD_REQ_NOTSUPP;
	}

	return status;
} 

We can see from disassembly this is a simple comparison to the maximum size. I’m mostly going to be looking at the guid structure since it’s located in FLASH below the metadata. Glitching the code in the red box below would create our required vulnerability:

The glitch is inserted with a ChipSHOUTER EMFI tool. The Trezor is held in bootloader mode with two spacers on the buttons, and the EMFI tool is positioned above the case, as shown below:

The entire setup is shown below, which has the ChipSHOUTER (bottom left), a ChipWhisperer-Lite (top left) for trigger delay, a Beagle 480 for USB sniffing/triggering (top center) and a switchable USB hub to power-cycle the Trezor when the EMFI triggers the various hard fault/stack smashing/memory corruption errors (top right).

The forced bootloader entry mode simplifies the glitch, as we can freely power cycle the device and try many glitches.

A glitch is timed based on a Total Phase USB analyzer. The USB request is sent from a host computer as shown below:

def get_winusb(dev, scope):
    """WinUSB Request is most useful for glitch attack"""  
    scope.io.glitch_lp = True #Enable glitch (actual trigger comes from Total Phase USB Analyzer)
    scope.arm()    
    resp = dev.ctrl_transfer(int('11000001', 2), ord('!'), 0x0, 0x05, 0xFFFF, timeout=1)
    resp = list(resp)    
    scope.io.glitch_lp = False #Disable glitch
    return resp

This corresponds to reading the “guid”. The Beagle480 is setup to generate a trigger on the first two bytes of this request:

To confirm the timing, I also compiled my own bootloader, and saw the sensitive operation was typically occurring in the 4.2 to 5.7uS after the Beagle480 trigger. There was some jitter due to the USB stack processing.

A ChipWhisperer-Lite is used to then generate a 4.4uS offset (empirically a good “waiting” place), after which an EMFI pulse is triggered. Should the 4.4uS offset happen to line up with the length checking/limiting, we can get a successful glitch.

A successful glitch will return much more data than expected – possibly up to the full 0xFFFF, but because things are getting corrupted it sometimes seems to be less. Also some OSes limited the maximum size you can request -you can find some references to that on the libusb mailing list. As a first step you might just try 0x1FF or something (anything larger than the correct 0x92 response). But here is a screen-shot showing three correct transfers (146 bytes transferred) followed by an incorrect one, which dumped 24800 bytes:

Here is an example metadata from another dump (this doesn’t correspond to the screen-shot above), note I never set a PIN as I had damaged the screen since the first device I tested with was being used for development as well:


Simulating the Glitch

Note you can “simulate” this glitch by simply commenting out the length checking operation in the WinUSB request. This allows you to confirm that should that operation be skipped, you can dump large chunks of memory including the metadata.

This simulation could be useful in validating some of the proposed fixes as well (I would highly suggest doing such testing as part of regular building).

Reliability Notes

Note due to the timing jitter the glitch is very unreliable (<0.1% success rate), however this typically translates to taking a few hours due to how quickly the search can be done. So it remains extremely practical since it seems reasonable for an attacker to have access to a wallet for a few hours.

I suspect this could be improved by doing the USB request from an embedded system (something like a GreatFET), which would allow me to synchronize a device to the internal state of the Trezor. This would mean the operation would be:

  1. Send a USB request (get descriptor etc).
  2. After the USB request comes back, send our WinUSB/glitch target request at a very defined amount of time after we received the USB request.
  3. Insert the glitch.

Simple Fixes / Countermeasures

1) The low-level USB functions should accept some absolute maximum size. For example, if you only ever do 64-byte transfers, never allow a larger transfer to occur by masking upper bits to force them to zero. Do this in multiple spots to make glitching past this more difficult.

2) The metadata needs to be guarded by invalid memory segments. Doing a read from a valid segment to the metadata should hit an invalid segment, causing an exception.

3) Move descriptor /metadata arrangement (less useful than #2 in practice).

Conclusions

EMFI is a simple way of abusing the USB stack in the Trezor. You’ll find a similar vulnerability in a number of USB stacks, meaning this type of attack should be something you validate against in your own devices.

More details of this example will be available in the book Jasper & I are working on for (eventual?) release.

Embedded World 2019 Conference Talk

At Embedded World I gave a talk on embedded security. There was also an associated paper, and I’m now making those available. I’ve also duplicated the paper contents in this blog post for your ease of access.

Download Slides (PPTX):

Click the above to download PPTX


ABSTRACT: As interconnected devices proliferate, security of those devices becomes more important. Two critical attacks can bypass many standard security mechanisms. These attacks are broadly known as side-channel attacks & fault injection attacks. This paper will introduce side-channel power analysis and fault injection attacks and their relevance to embedded systems. Examples of attacks are given, along with a short discussion of countermeasures and effectiveness. The use of open-source tools is highlighted, allowing the reader the chance to better understand these attacks with hands-on examples.

Introduction

Side-channel attacks are the broad class given to attacks which rely on “additional information” that is accidentally leaked. A variety of such side-channels exist, such as the time an algorithm takes to execute can betray information about the code paths taken in the algorithm. Of great interest to embedded developers is side channel power analysis, first introduced by Kocher et al. in 1999 [1]. This attack takes advantage of a small piece of information – the data being processed by a system affects the power consumption of that system. This allows us to break advanced cryptography systems such as recovering an AES-256 key in a matter of minutes. These attacks do not rely on substantial resources – they can be performed with commodity hardware and for less than $50. A second class of attack will be known as fault injection attacks. They allow us to modify the program flow of code, which can cause a variety of security flaws to be exploited. This paper will briefly introduce those two methods of attacks and discuss how engineers can understand them to develop effective countermeasures.

Power Analysis for Algorithm Flow

The most basic form of power analysis attack is simple power analysis. In this method we will extract information about the algorithm flow. This could be used to directly extract key bits where changes in program flows reveal key information (such as with RSA), but can also be used to extract information such as timing that simplifies further attacks. Observe a simple password check which checks a byte of the password at a time. The execution time through this algorithm would reveal which password byte was incorrect, allowing an attacker the ability to quickly brute-force the algorithm. A password of ADBC would entail only the guess sequence “A/A..B..C..D/A..B../A..B…C” to find the correct password, as once the correct letter is found for one digit the guess algorithm can move onto the next digit.

Such an attack could be performed from the communications protocol. But many systems will add a random delay before returning the results. With power analysis we could see the unique signatures in the power trace, as in Figure 1. Fig. 1. A simple password check shows how many iterations through the loop we took.

Figure 1: Loop Iterations in the Power Trace

These power measurement examples are taken with the ChipWhisperer project. Here the power measurements are done by inserting a shunt resistor into the device power pin, and using the fact that a change in current will cause a change in voltage across the resistor. The decoupling capacitors are removed in this example to provide a clean signal. This is shown in Figure 2.

Continue reading Embedded World 2019 Conference Talk

More Research, More Fun – I’m now an Assistant Professor

Are you interested in this area of research? If you’ve followed some of my work you know I enjoy a combination of fundamental research & hands-on practical experiences.

It led me to co-found NewAE Technology Inc out of my PhD, with the objective of taking some of the research I was doing and pushing it ever further out into the world. I’m going to be continuing that work as C.T.O., but at the same time taking a leap forward in building up a larger research group under an academic affiliation.

I’ve joined Dalhousie University as an assistant professor in the electrical & computer engineering department. This is a bit of a unique position as I’m also going to be helping with some of the new innovation work being done in the “IDEA Building”, which means I’ll be mandated (and thus have time) to work with companies interested in cyber-security (emphasizing the sort of cyberphysical work I do, like IoT and automotive).

I’ll be shortly looking for students as well – if you are interested in a MASc or PhD in this area, I’d love to hear from you! Get in touch with my Dalhousie email (COFLYNN – AT – DAL.CA), if you don’t hear back sometimes I’m travelling quite a bit so may be slow, so please follow up to make sure I didn’t drop it. Or say hello at a conference – I’ll be at RECON and Black Hat in the next few months.

More details & update on this to come, but it’s an exciting chance for me to continue pushing the fundamental research I love, while engaging the local start-up community and helping encourage students that starting a business out of research isn’t such a bad idea.

Nova Scotia Embarrassment –

Just a quick post to have someone with the text. In case you aren’t aware, Nova Scotia’s “Freedom of Information and Protection of Privacy” (FOIPOP) system allows you to request various information from the government, including information about yourself. When you request information about yourself it’s not redacted (i.e., your SIN and other information they have would be in the document), but when you request it about someone/something else information is redacted to protect their privacy.

They were serving these documents using a system with URLs like “https://foipop.novascotia.ca/foia/views/_AttachmentDownload.jsp?attachmentRSN=1234”, where the last number was the document. Which is fine until they decided to use this for both the sensitive and non-sensitive one, with no log-in or password checks. To a point, these documents were automatically indexed by Google and other services, as they didn’t even put a ROBOTS.txt is seems.

Evan D’Entremont has a great write-up, so I’ll just refer you there for details.

While somebody downloaded documents they “weren’t supposed to”, and they are now claiming he is a hacker. Note most of the documents accessed were public, and there was no way to tell them apart based on URL (so it’s not even an attempt at hacking). The following is my open letter to the province regarding this silliness:


April 17, 2018

The Honourable Stephen McNeil, Premier of Nova Scotia

Re: Nova Scotia handling of FOIPOP information leak

I’m writing to you with considerable alarm regarding the response to the exposure of confidential information via the FOIPOP portal. In particular, I am greatly alarmed by the handling of an individual accessing a public government website.

It is clear the document storage and display system was designed for public documents only, as no attempt was made to authorize or validate the user. I can only assume this was a miscommunication about the intended use of this particular document storage system, as many of the documents appear on Google and other archives. Notably, even the most basic web configurations have a list of non-public directories which search engines such as Google will not access out of courtesy. There is no authentication or lock on these pages eith­er, but the fact that no attempt was made to prevent such access clearly points to this being a publicly accessible document repository.

Attempts to claim this was somehow a “hack” or even “vulnerability exploitation” do not pass muster. Neither do explanations make sense that this is a case of someone stealing an unlocked bicycle, and thus they have still done something wrong. Rather this is a case of someone (hint – not the person that had their house stormed) leaving sensitive documents in the library stacks, and someone else finding them while looking through the books. They were placed in a public location without any access control – the “attacker” simply picked them up from this public space. In fact, in this case the sensitive documents even had the same labeling and numbering system as the public books on the shelf. They are completely indistinguishable until you look at the contents.

Despite this, the person finding the documents is being aggressively handled, and a story being created that is attempting to spin them into the antagonist. Heavy-handed attempts at pursuing “computer crime” have been widely recognized as being counter-productive of achieving a more productive and secure society – even when some actual crime may have occurred (which in itself appears questionable for the case at hand).

On one hand, the government is claiming they want to encourage investment and growth of technology in Nova Scotia. Cyber-security in particular has been recognized as a particular growth area of importance to Canada, with the latest federal budget spending $1 billion on cybersecurity. But the handling of this case sends a crystal-clear message to potential researchers and entrepreneurs that Nova Scotia is not somewhere you want to be, as they are still working under long disproven and outdated cyber-security enforcement tactics.

I do not believe the current outcome was malicious, but the result of many levels of confusion, miscommunication, and attempts to divert blame. Ultimately this miscommunication resulted in Halifax Regional Police conducting a raid under the pretense that a computer crime occurred.

There is still some hope of salvaging Nova Scotia’s reputation and future ability to attract critical cyber-security talent from across Canada and the world. This would require a frank admission of the failures within the government (this does not require scapegoating any specific employee), while also outlining remediation steps to provide justice for the “hacker”, and a plan to prevent such heavy-handed reactions from occurring in the future (such as some level of expert validation of computer crime complaints). Regaining public trust regarding handling of sensitive data involves additional work, but I believe the first three items outlined are the most time-critical for the matter at hand.

Respectfully,

Colin O’Flynn, Ph.D.

C.T.O., NewAE Technology Inc.


 

MeatBag PnP – Simple Pick-n-Place

Have you ever hand-built a PCB prototype with lots of parts? If so you’ll know the annoyance of hand-building something from a big stack of Digi-Key parts. Having to Ctrl-F the part value in the design, and dealing with hits on both top & bottom side. Instead I’m introducing Meat-Bag Pick-n-Place, which helps you the human meatbag become a PnP machine! Here’s a photo of it running:

You can either click on an item, and it finds the first hit of it (i.e., click on a 200-ohm resistor) and shows you. You can then use spacebar to move through the placement list. It also interfaces to barcode scanners so you can just scan Mouser or Digikey bags. Here’s a short video demo:

 

 

All this is posted on the GitHub Repo, so hopefully you find it useful!

PhD Thesis Finally Done

If you’ve seen my presentations anytime over the past few years, you’ll know the introduction about “PhD Student at Dalhousie University finishing ‘soon'” has been the claim for the past several years. Finally ‘soon’ actually happened!

You can see my complete thesis entitled “A Framework for Embedded Hardware Security Analysis” on the DalSpace website. It’s been a ton of fun doing the PhD, and I’ve had a lot of help over the years which I’ve very grateful for. For the foreseeable future I’ll be continuing to spin up NewAE Technology Inc., and keeping my ChipWhisperer project alive.

Black Hat Slides – PIN-Protected HD Enclosure / MB86C311A Research

This is a quick post to link to slides from my Black Hat USA 2016 work.

This work stands directly on the work done by Joffrey Czarny & Raphaël Rigo presented at HardWear.io last year (2015). They discovered the issues w.r.t. the stream-mode cipher being used by all manufactures on the MB86C311A, and the fact that secrets are stored on the HD itself. Their work is available at:

They have some newer work coming out which looks to be very interesting, so please keep your eyes out for that. Anyway onto my stuff. The following is a link to my slides:

Brute-Forcing Lockdown Harddrive PIN Codes [Slides]

 

A Low-Cost X-Y Scanner using 3D Printer

This summer, our summer intern Greg d’Eon made a quick project to build a X-Y Scanner from a 3D printer (by ‘quick’, I mean it took him less than 2 days!). You can see the source code up on GitHub. Anyway, 3D printers are very nice as they have fairly high resolution and fairly low cost. Here’s a quick video:

We’re using it to measure EM emissions frequencies over a PCB, but you could also use this for side-channel emissions, or fault injection. While the resolution might not be high enough for getting at specific features on a chip surface, it can still be used for general positioning.

With your EM emissions, you can graph X-Y vs. amplitude – here I’ve constrained the range to get an idea where the 96 MHz emissions are concentrated. Probably more interesting would have been to use a 2D plot with colour overlaid over the PCB design:em_plotYou can also do things like plot frequency vs. position with strength of the signal given by color. In the following graph the X position is fixed, and only the Y position is varied. You can see here the 96MHz oscillator of the SAM3U microcontroller on the ChipWhisperer-Lite for example:

650MHz_05

 

Low-Cost SMD Soldering Setup

The following blog post shows some details of my SMD soldering process. This was based on a larger video I did (linked below) showing the entire soldering process.

Video of Soldering Setup

The following shows me soldering a complete board with BGA device.

Equipment Used

In the above video, there are several pieces of equipment used. The following shows you some of the important ones.

Reflow Oven

I’m using a T962A reflow oven. I recommend this over the T962, which is a smaller version. The T962A has 3 heat lamps so has a more even heat distribution. Be aware you can’t use the full surface area – about the middle half I find is successful, but depends a little on complexity of the PCB.

I specifically purchased mine from this seller on AliExpress, check other sellers as prices change over time. You might turn it on quickly to confirm it works, but before doing much there are some important fixes:

  • Removing masking tape, replace with Kapton (Polymide) tape. See instructables post for details.
  • Fixing missing ground connections. Some versions have poor grounding between the outer (metal!) case and the wall plug. See the wiki page for a photo of this fix.
  • Updating the firmware and adding a cold-junction sensor. This is the most complex task, and requires soldering a DS18B20 to the mainboard, then using a USB-Serial adapter to reflash the firmware. See the front page of the T962-Improvements Github Repo, which has links to the required soldering. There is also an optional fix to reduce the very noisy small fan.

Fume Hood

I built a fume hood out of the following:

  • 2×4’s for frame.
  • Thick plastic drop-sheet.
  • Powerful vent booster fan with variable speed control.
  • Active charcoal oven range hood filter (mounted in top of fume hood).
  • Active charcoal filter for car cabin (mounted in cardboard box used as exhaust).

You can also improve one out of a range hood from an oven. See video for general fume hood construction.

Manual Pick-n-Place

FIG4

This requires three things:

  1. Vacuum pump, which you can make from a Tetra Whisper pump (see instructables link). Get some of the nice silicon tubing at the same time (like $3 from Amazon).
  2. Syringe with hole drilled into body. You can get syringes (don’t need the pointy bit!) from pharmacy, or order from Newark/Digikey. When you cover the hole, you force the vacuum through the tip, picking up the part. Release your finger from the hole to drop the part. See the above video for details.
  3. The tips for pick and place, which are “Luer Lock” needles bent slightly (for small parts) or commercially available tips (for larger parts).

The tips are the only somewhat tricky thing. I had a good selection from a previous SMD picker tool, something like this kit for example (which is Chip Quick Inc. part #V8910). These tips are actually the same “Luer Lock” that fits into syringes, check E-Bay for cheaper kits:

V8910 Chip Quik Inc. | V8910-ND DigiKey Electronics

You can also buy Chip Quik Inc part #VCS-9-B which has a bunch of these tips. It’s not the cheapest way, but if you are in a hurry will do! But all of these tips are for larger parts (i.e. maybe SOT23-3 at smallest). If you get into chip resistors, you need to go smaller.

For the small parts, you can bend “needle tips” slightly. You can buy packs of 50 from Digikey (search “Luer Lock”), but might find it cheaper to get individual ones from either medical supply places, or buying products which use them. For example some static-safe squeeze bottles come with a few tips. Again the expensive but easy route is Chip Quik part # SMDTA200 which has a bunch of different sized tips.

http://media.digikey.com/Photos/Apex%20Tool%20Photos/KDS2312P.JPG

Stencils

There is three main options for stencils:

  1. Laser cut stainless steel.
  2. Third-party cut Kapton film.
  3. Self-cut Kapton/Mylar film.

For laser-cut stainless steel, this can typically be ordered with your PCB fab. For example 3PCB.com and Dirty PCBs offer them very cheaply (~$25) when ordering PCBs. This is almost always the best choice, as the stainless steel stencils are very reliable and I’ve had great success with BGA devices.

You can also use third-party services to cut Mylar or Kapton film for you. OSHStencils is one example of a supplier.

Finally, you can make your own. You’ll need some practice to cut BGA parts, but it’s quite easy to cut stencils for less demanding applications. I have a previous blog post on my method.

I’ve been making my own stencils with this process for some time with great success.

FIG3

Solder Paste/Squeegee

I purchased the squeegee from Dirty PCBs. There are some other blog posts on squeegee options you might look at.

I generally just buy solder past from Digikey. Digikey does a great job of cheaply shipping to Canada, and the paste comes in an awesome cold pack thingy that keeps it cool during the trip. Chip Quik (again with the Chip Quik sorry, I don’t have a connection with them but just end up using their stuff!) sells some nice small syringes. Be aware it does have a shelf life… I’ve used past about 6-12 months paste that date, but you will eventually see issues (balling, flux separates). I recommend keeping to the suggested date to avoid giving yourself the headache of discovering your paste is bad after you’ve tried soldering your PCB. The cost of all your parts is probably a lot more expensive than the cost of replacing your paste.