Stop Doing Tamper Evident Security Seals Wrong!

Disclosures:  Digital Bitbox sent me two devices to take a look at.  I sent them no money in return.  I am going to destroy one and keep the other.  Nobody reviews my content before I post it, and my posts are my own opinions.

A pair of Digital Bitboxes just arrived at stellaw.info HQ, and I've got to address this straight away -- even before a Teardown/First Impressions post.  After removing the box from a sealed anti-static bag, I saw this:

A tamper-evident seal!

Branded even!  The shiny hologram has 'security' repeated in the background.

Seal completely intact, and the product easily skips out of the 'secure' packaging.

Seal intact, both the bitbox and sd card easily removed.  This is 100% of the contents of the box. (I broke the seal and opened the box later to confirm this.)

Stop half-assing security measures.

I thought we all learned this exact lesson from the Mycelium Entropy's shameful showing. 

The purpose of a tamper-evident seal is to make it clear that something has been opened or tampered with upon inspection.  These seals can be a deterrent against some adversaries who do not have the tools or skills to bypass them.  In this case, the bypass was slightly squeezing the box and letting the product slide out the side.

This is security theater.  This seal serves no purpose but to communicate that either:

1. The manufacturer thinks that their customers are idiots and will be fooled into thinking that this shiny piece of tape adds any amount of security.  or:
2. The manufacturer does not understand how to implement security features and wants to make that clear upon first impressions.

Either case is pretty lousy.  I guess they aren't mutually exclusive.  From the first moments of experiencing their product, my level of confidence in Digital Bitbox to not screw up other security details is not high.

Hardware Bitcoin wallets are not toys.  They are financial products that you are asking your users to trust with their money.  This is important.  Get the details right.  If you are going to include a security feature, make sure it works.

In this case, it would be cheaper and more effective to not include a seal at all.  You would not have had to spend the money in procuring a custom seal, and the time in applying them to the box -- and you would not be implying that part of the security model of your device is a strip of shiny tape poorly applied.

Teardown and second impressions coming soon. 

DINOSAUR HIPHOP ZERO alpha/prototype dev kits for sale

Since I don't need 50 Core205R dev boards with STM32F205RGT6 chips myself, I put together a limited number of DINOSAUR HIPHOP ZERO kits available for purchase.

ALL ASSEMBLY REQUIRED.  This is a prototype / dev kit for enthusiasts who know what they are doing.  If the instructions at http://dinosaur.hiphop are not clear enough, then this isnt for you.

What's included:

     Core205R module with STM32F205RGT6 MCU (1MB Flash)

     OLED 2864 display module

     DINOSAUR HIPHOP ZERO breakout pcb

     Two buttons

What's not included:

     solder

     (optional) headers (if you want to be able to separate the two parts like a 'shield')

     (optional) 8Mhz crystal.  The Core205R module comes with a 25Mhz crystal, which is okay, but requires some source hackery to make it work.  If you happen to have an 8Mhz crystal lying around, swap it out and make your life easier

     hand holding

Why might I want this?

DINOSAUR HIPHOP ZERO is a Trezor hardware clone.  This is the hardware inside of a Trezor, in a different form-factor.  Hardware debugging is accessible, and therefore this makes for a pretty nice Trezor dev kit.

You can assemble your own kit, compile your own bootloader that checks for your signature on firmwares you compile and sign yourself.

If you intend to use this as a daily driver hardware wallet, you probably don't want to do that.  I mean, you could -- but that's not the intention.

$75 shipped.

Yes, I know that's expensive.

inquire here: gbg@stellaw.info

I am in no way affiliated with SatoshiLabs, the designers and manufacturers of the Trezor.

Bitlox first impressions and teardown

Bitlox reached out to me and asked if they could send me one of their hardware wallets to look at.  I asked for two, so I could tear one apart and have one for not tearing apart.  The two Bitlox wallets arrived the other day.  They sent these to me for no cost, and I made no promises about the content I post about their product.  Nobody reviews or approves my content before I post it.

I wouldn't use a Bitlox.

There are several reasons, but the first reason trumps all others, and that's because it is not open source.  The firmware is not available, and even after ripping one apart, I still do not know what hardware makes it tick.  I'll get back to that in a moment.

Any closed source hardware/software wallet is a non-starter for me (and should be for you).  If I'm interested in Bitcoin enough to purchase a dedicated device to store them, then I likely care about Bitcoin's open-source nature.  Unreproducable solutions need not apply.  Open source money wants to live in open source hardware.

Therefore this post is a 'first impressions' of the Bitlox hardware alone, and I'm unlikely to spend any time with the software used to interact with the Bitlox device to make a well-informed follow-up on the software components.

There's still enough to talk about:

Nice large e-ink screen.  About the height and width of a credit card, but about 4mm thick

At first glance, the Bitlox feels premium -- large, clear e-ink screen, dense but not too heavy, no case twisting (unlike the cheap feel of the Case wallet), and classy red accents in-between the keys.

But all that fades after the first press of one of those buttons.  They are smushy beyond smushy, and the feel of the buttons at the left and right sides is far different than the ones in the middle.  The '3', '4', '8', and '9' keys have a distinct point during the button travel where the press is activated, as you would expect a button to feel, but the buttons on either end have zero travel -- Zero!  It feels like I'm pressing on a hard surface, and when some pressure threshold is exceeded, the button press is registered.  I wouldn't want this behavior for any buttons, but this is especially terrible for the 'checkmark' button, presumably used for confirming actions such as Bitcoin transactions.

There's some goo in the upper right corner of the screen underneath the protective outer surface layer.  This appears on both units.

The front surface of the Bitlox is bowed out quite a bit, which I believe contributes to the terrible feel of the keyboard.  Here, It feels like they are trying to fit in a battery that's too thick, but are including it anyway.  This isnt the case, but that's the impression I had before popping it open.

Its hard to capture how not flat the front surface of the Bitlox is.  Also, look at those keys!  They will catch on things in your pocket and bend out of position quite easily.  I drink Mt. Dew.

In reality, its just a terrible keyboard design.

This is pretty terrible.  I didnt test it, but I doubt this would be moisture/water resistant at all.

The connection between the keyboard and the pcb is a direct edge soldering that separated when prying the two pieces apart

The connection between the two pieces is visible along the bottom edge of the left part, to the right of the shiny silver battery.

The back of the keyboard along with soldered edge connection

The components are on the bottom of the pcb, and there was no easy way to get the pcb out of the bottom of the case.  There was much spudging, and once separated, it was clear why

The space between the component side of the pcb and the rear shell is partially filled with a hardened black epoxy.

The black epoxy bonded the pcb to the rear shell tightly enough that come components were ripped off the board when I pried them apart.

SMT components embedded in hardened black epoxy

And here's a view of the component side of the pcb.  The bluetooth module appears to be an off-the-shelf module, there's an ARM chip from Atmel, and another small atmel mcu - likely a USB-to-serial bridge.

That's alot of passives.  There's also what looks like a jtag/debugging header over there on the right side.  This board is dead due to parts being embedded in the epoxy, but I could imagine that a hole could be carefully drilled right at that location on a working device to get access to that header to test to see if its enabled.  I'd check the firmware source code, but its not available.

Off-the-shelf bluetooth module

"But gbg, " you say, "what's the part number on the main Atmel chip?"  I'd give it to you, but its been scratched off to hide its identity.

Can you read the Atmel part number?  Nope!  You can't!

Under the microscope, I think I can make out that the part number starts with 'ATSAM' and ends with 'C':

Why would they do this?  What are they trying to hide?  Who would ever trust this with their Bitcoins?

And finally, the price starts at $199.  Unless you *really* need a hardware wallet with bluetooth (you don't), pass on the Bitlox.  

Instead, educate yourself on the risks, and purchase a cheap Trezor clone, a Trezor from SatoshiLabs, or build your own Trezor depending on your risk tolerance.

Trezor *is* open source hardware!

One of my major criticisms of Trezor has not been valid since <I'm not sure when>!

At some point, SatoshiLabs released the EagleCAD files for the Trezor, available here:  https://github.com/trezor/trezor-hw/tree/master/electronics

Well done, SatoshiLabs!  You use the 'open source hardware' label without shame.

I have not yet looked at the posted CAD files in detail, but at first glance they appear to be correct and complete.

From: https://github.com/trezor/trezor-hw/blob/master/electronics/trezor.brd.png

I wonder when the exact clones are going to hit the market?  Or have they already?  Is the Trezor in your pocket genuine?

I built my own Trezor clone: DINOSAUR HIPHOP ZERO

Through considerable effort, I was able to build my own instance of a Trezor.

I call it DINOSAUR HIPHOP ZERO.

I will be releasing the Kicad files (modifiable full schematics) for the breakout board, and the minor tweaks to the Trezor source required to make your own! (Probably just after the holidays)

@__gbg__

Breakout Board

So I can run my own bootloader code on the Blank Arrow eWallet-based development platform.

But I can't use a debugger on them.

So, I need a different solution.

I found the CorexxR dev board from Waveshare.   Its a breakout board for the MCU that the Trezor uses, and also has the basic circuits required to get the chip running - USB, power circuits, a crystal, and breakouts for all the pins on the chip.

The problem is that the MCU on the Core205R is the STM32F205RBT, which has 128k of flash.  The Trezor's STM32F205RET has 512k.

So close!

I read the specifications, and found that all the STM32F205 chips are pin-compatable, so Waveshare could just solder down a equivalent part that has more flash, then I'd be happy.

So I emailed them and asked if they could do this for me.  They said they could -- if I ordered at least 50.

These have STM32F305RGT6 MCUs, with 1024k of flash.

Trezor Clones and Bootloader Development Platform

I still want to run a bootloader that I compile that will check for my signatures on firmwares that I compile.

The only way to do this is to start with a blank MCU and write down my bootloader.

As I talked about in the last post, SatoshiLabs does not make it easy to build your own Trezor from base components.

There are clone devices on the market, so I took a decently detailed look at how they compare to the Trezor and what differentiates them.  Watch the video for some of the details.

But I wanted a trezor clone with a blank chip.  I emailed Black Arrow to see if they could help me, and they sent me a handful of Black Arrow eWallets with blank chips and a little wire loop that extends outside the enclosure.

The wire connects the BOOT0 pin to high (1), which allows the MCU to boot into the STM bootloader (DFU mode) that allows me to write down my own bootloader and firmwares.  Cutting the wire reverts the pin to low (0) and will allow the device to start up into the application code.

Some source modifications to the bootloader code to remove the write protection enabling parts, and soldering the wire loop to header pins allow me to use this device as a bootloader development platform, alternating between writing down my own bootloader and running it and making changes and writing down a new bootloader again.

I could also design my own Evil bootloader and load it onto these devices, remove the wire loop, and they would physically look just like a standard BlackArrow eWallet.  I could then sell them on eBay or Amazon as if they were legitimate.

Open Source and Firefox and Trezor

I'm a software guy.

When I think about open source software, the first project that comes to mind is Firefox.

If I want my own instance of Firefox, it is easy to download everything I need from Mozilla and compile my own Firefox from source.  Mozilla provides simple instructions and commands to copy and paste into my terminal to help me do so.  Makefiles are provided to make this easy.

I can make changes to the source code and easily recompile if I want to make my own customizations.

This is how 'open' projects should work.

SatoshiLabs publishes their firmware source code and bootloader source code (finally).  I can compile my own firmware and load it onto my Trezor, but I see an 'Unofficial' warning when running it.

I can compile my own bootloader, but I have no way to use it because the bootloader on a Trezor is locked and unmodifiable.

But the Trezor is also 'open source hardware', right?  I can just build my own instance of the hardware that has not yet been locked and use my own compiled bootloader.  Its 'open', so it should be easy!

The reality is not as straightforward.  The only thing that SatoshiLabs provides to support their claim that the Trezor is 'open source hardware' is a pdf of the schematic:

https://doc.satoshilabs.com/trezor-tech/hardware.html

A pdf of the schematic is not enough to build an instance of a piece of hardware.  I can't send a pdf of a schematic to a pdb fabricator and receive a working board in return. A pdf of a schematic is not a Makefile.

This would be like Mozilla saying that all we need to do to build our own Firefox instance is to write a program that implements the html and javascript specifications.

If Mozilla did that, there's no way anyone would believe their claim that Firefox is open.

This is what SatoshiLabs is doing with the Trezor.  They are claiming that the Trezor is open source hardware and pointing to a picture of a schematic to substantiate their claim.

The Trezor is not open-source hardware.  It is not easy to make your instance of a Trezor and incorporate your own changes.

Trezor Bootloader Source

SatoshiLabs shipped their 'open source' Trezor product without sharing its bootloader source code.

When asked about this via their support email and bitcointalk.org forums, SL said they were not going to release the bootloader source code because this would open up the opportunity for clones to enter the market.

This is true -- but then you cannot market your device as 'open source' if you aren't going to release the source openly.

SL did eventually release the bootloader source code for the 1.2.5 bootloader after I shamed them on Reddit.

The initial batch of metal Trezors shipped with bootloader 1.2.0, and SatoshiLabs has not released the associated source code.

VIDEO CLARIFICATION: I have not been able to reproduce the 1.2.0 bootloader from source because the code for the 1.2.0 version has not been posted. (as far as I can tell)

Trezor, Hotdogs, and Skydiving

Because the Trezor bootloader checks for SL-signed firmwares, it is impractical to run your own compiled firmwares.

One thing you can do is compile the firmware source code that corresponds with a new firmware update from SL and check that those bytes match the bytes in the firmware signed and distributed by SL.

But what if I don't want all the changes that SatoshiLabs has made?  They have been bundling together security enhancements with 'new features' that I might not want.

I only want my Bitcoin hardware wallet to do Bitcoin things.  I don't want my Bitcoin wallet to perform ssh logins or display custom artwork just like I don't want my local bank branch to sell hotdogs from their vault, or my commercial flight to also offer skydiving lessons.  These represent risks that I don't want to incur -- and shouldn't have to.

Therefore, you are implicitly trusting SatoshiLabs when you upgrade your Trezor's firmware.  You are accepting the security updates and the new features, whether you want them or not.

Trezor Memory Layout

Overview of the Trezor's memory layout and memory protection features.

The MCU powering a Trezor is the STM32F205RET.  This chip is an ARM core with many peripherals on die including GPIO, SPI, USB, and Flash.  Attached to these are the Trezor's buttons, the OLED screen, USB for power and data, and the Trezor's firmware, bootloader, and metadata storage -- including private key material.

The Flash is structured as follows:

32k of Bootloader

32k of Metadata Storage

448k of space for the firmware

When a Trezor is powered up, the bootloader is executed.  The bootloader initializes the hardware, checks the signature of the firmware against a signature baked into the bootloader to make sure that the firmware was signed by SatoshiLabs.  If it was, then the bootloader cleanly transfers execution to the firmware.  If the signature does not match, then a warning stating that the firmware is not official, and the user must select 'OK' before the bootloader transfers control to the firmware.

The memory where the bootloader resides is write protected.  The signature that the bootloader checks for cannot be updated.

This is a fine method to alert a user in the case where an Evil firmware were to be inserted without the user's knowledge.  The 'unofficial' warning would appear on the screen and the user would know to stop using that device.

The problem is when you want to run a firmware that you compiled yourself.  In that case, the Trezor will display the 'unofficial' warning, but your Trezor has a firmware with code that you want to run.  You can click 'OK' and have it continue, but you do not have positive confirmation that the Trezor is running your firmware, and not Evil firmware.  The device behaves the same way.

When the Trezor powers up, the first thing the MCU checks is the state of the BOOT0 pin.  If the pin is low (0), then the MCU boots into System Memory that contains a manufacturer (STM) bootloader that can be used to program chips (DFU Mode).  If BOOT0 is high(1), then the MCU boots into application flash memory, which is the beginning of the Trezor bootloader.

In the Trezor circuit, BOOT0 is hardwired to 1, and therefore will always boot into the Trezor bootloader.

Case Wallet Teardown

Qi wireless charger

How would you expect to turn this on? 

Wobbles when setting on its face due to face button design. Covering hologram sticker with serial number.  Generic hologram sticker could be purchased by anyone inexpensively.  Why do companies add these useless things?

Camera not especially well protected.  

Buttons feel cheap and mushy. Cutout around fingerprint scanner is off center.  

Front face is super easy to peel off.  

Buttons are embedded into the thin front face and connected with a thin ribbon connector in the middle of the left edge, which I'm surely about to break. Also, the device is about a quarter inch thick -- far too thick to 'fit in my wallet' 

Man, the insides are full of this black sticky tar adhesive. Ugh.  

The ring there is the wireless charger loop

The other side of the unused 3M adhesive strip

The screen is tar glued to the battery.  I damaged the screen while opening up the unit. 

Cell module and STM32F437.   Networking right next to private keys (I'm assuming - case hasn't posted any source code)

3.7V, 270mAh

What a mess of non-repairable goo! 

KeepKey is available for sale

For $239.  

That's at least 139 too many dollars, imho. 

Lavender

Right at home. And ships with bootloader v1.2.5

Read more about the charity auction here:

https://medium.com/@satoshilabs/another-240-healthy-babies-thanks-to-trezor-fans-in-direct-relief-campaign-b4adf7629607

Cheers!

KeepKey first impressions and teardown

I emailed the KeepKey folks, and they sent me a developer unit!

So I guess the 'full disclosure' here is that they sent this to me and I didnt send them any money in exchange.  Or the promise of anything.  They really didnt ask me much other than the address to send it to.

Oh well.  Now we're all on the same page here.

It comes in a classy box.

This is kinda-sorta what it looked like when I opened the box for the first time.  Its a lovely shade of green inside.

It comes with a nice fabric-covered USB cable and a quality paper to write down your seed words.

The back of it is a pleasant aluminum.

The front is plastic, with a tinted window for the screen to shine through.  You can see the damaged clips that held the two halves together.

It was a bugger getting the thing apart.  Those retention clips are solid, and its not going to go back together in any pretty way.  Inside there is a custom molded plastic bracket that holds the board and screen in place, and that was glued solidly in place.

I dont believe that it would hold up submerged in water, but I'd say its fairly tamper-evident.

And here's the guts.  I havent looked at this in close detail yet, but there are some nice surprizes in here.  The ZIF socket for the screen is very nice, the silkscreen comments many components nicely, and it looks like there's a set of debugging pads nicely lined up in the lower left there.

There's even a pair of LEDs on the board that most people will never see.  I assume those will be gone in future revs.

I was hoping to see a second button hidden on the board.  The one button is labeled SW2, but I didnt find a SW1 on there.  This is a fork of Trezor, but with the omission of a second button, there's no hope of running original Trezor code on this.  What a shame for a product with such great fit and finish.

The backside is not very interesting.

powered by an STM32F205RGT6, along with its full MB of flash (more than Trezor, same as the Black Arrow eWallet)

. . .and she still works!  I'll be taking a look at the software and the user experience soon.

From a hardware quality perspective, KeepKey is solidly designed and feels 'premium'.  I have no idea what the expected price is going to be, but I sure hope they can be very competitive with Trezor pricing.  

Another Trezor Clone/Fork is coming!

http://www.keepkey.com/

These guys appear to be doing a little more than just a clone, *and* they've already posted firmware and bootloader source.

Seems promising.

But I haven't found the hardware schematics / gerber files yet. . .

Bootloader Version

SatoshiLabs is still shipping bootloader version 1.2.5

Memory Protection Test

I was perusing the Trezor code and noticed this function:

This is called early in the bootloader and checks if the memory protections have been set, and if they are have not been, then it sets them.

The setting is permanent and the code will only be hit once -- the first time the chip powers up into application mode after the bootloader has been written to the chip.

But has this happened before or after the wallet has been put into the retail packaging?

Lets find out!

First, lets make sure we have a valid way of testing by using a fresh factory blank chip:

With the factory fresh chip in this rig and the boot pins in this configuration, I can verify that the chip boots into DFU mode via JTAG and openOCD.

So lets sacrifice a factory sealed wallet.  For Science!

Apply tools:

Extracted safely:

Now the sad conclusion: when testing this chip in the test rig, openOCD would not communicate with the chip.  This implies that BWallet powers up each unit in the factory in application mode, executing the code that trips the memory protection fuses.

I'd like to test a Trezor in a similar way.  Donate if you are interested!

Trezor Private Key extraction via power analysis

Check this out.

http://johoe.mooo.com/trezor-power-analysis/

johoe's work here is excellent, but also something a moderately determined mere mortal could duplicate.

Mycelium Entropy Impressions

Today, my Mycelium Entropy arrived.  I was excited about this one -- a simple device designed to do one simple thing.

Here are my initial thoughts:

Nice packaging.  Decent enough build quality.  What's that on the right side?

Branded holographic security seal?

This, my friends, is called "Security Theater."  The 'security seal' is *easily* bypassed.  Makes me wonder what other security 'features' they got boneheadedly wrong.

Its an ATMEL ATSAM4LS4 ARM Coretx M proc

wat.  "We're 'open source'!  So f*ck you, you're on your own!"

This product is a toy.  This is clever, but does not instill any confidence in their ability to make a financial product.

I'd reach for any of the other three products before the Mycelium Entropy.

These are just initial impressions, but man am I disappointed with the presentation and apparent lack of confidence in their own product.

What's the purpose of the holographic sticker?  It fails miserably as a tamper-evident seal.  Its just to look pretty?  Its got Mycelium branding, so some (non-insignificant) part of the price of this device went to a shiny sticker that some folks might interpret incorrectly as adding to its security.  blech.

This is another Bitcoin hardware company throwing around that term 'open source'.  Sure, there's a repo with some code, but the way I found out what processor was running inside was by disassembling mine.

More to come.

Drop your questions for me in the comments section.

(Donations appreciated here: 1Adq8SP8WBWJGHyq8N3bGty8n1m9A3ms81)