[Feedback request] Making sure the shipped device hasn't been tampered with during transport

[mathieu...@gmail.com]

Hello everyone,

A user popped up in our IRC channel and asked a very interesting question: how could someone make sure that the device he received hasn't been tampered with?

Let's imagine the worst possible attack scenario:

- attacker intercept backer's package

- attacker opens the Mooltipass device, takes the main PCB containing the microcontroller

- attacker produces all of the Mooltipass mechanical pieces (box, front panel, screen...)

- attacker adds a signal sniffing device on the main PCB 

- attacker reassembles everything, the mooltipass looks as new

- device is shipped to the backer

The main point here is that physical tampering is nearly impossible to detect. How could the backers know they didn't receive an original device?

We therefore though of different solutions and would like to get your feedback on them:

Solution 1: Offer the backer to change the chosen courrier (we'd have to setup some billing system for the extra costs)

Solution 2: Ship the devices with their front panel not assembled (see video) to allow the backer to reprogram the main microcontroller with the firmware downloaded from our repository.

What do you think?

Mathieu & the dev team

[Hannes Werner]

+1 for Solution 2

> --
> You received this message because you are subscribed to the Google Groups
> "mooltipass" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mooltipass+...@googlegroups.com.
> To post to this group, send email to moolt...@googlegroups.com.
> Visit this group at http://groups.google.com/group/mooltipass.
> For more options, visit https://groups.google.com/d/optout.

[Günther Hutzl]

+1 for solution 2

[Kaspar Emanuel]

Another +1 for solution 2.

On 27 March 2015 at 11:38, Günther Hutzl <guenthe...@gmail.com> wrote:

+1 for solution 2

[Jesse Vallaro]

Even though everything is open source and available would there be a way to public-private key ‎the transfer between the app and the mooltipass and have it be a secret private key? 

--
~Jesse

From: Günther Hutzl Sent: Friday, March 27, 2015 7:38 AM To: moolt...@googlegroups.com Cc: mathieu...@gmail.com Subject: Re: [mooltipass] [Feedback request] Making sure the shipped device hasn't been tampered with during transport

+1 for solution 2

[mathieu...@gmail.com]

Hello Jesse,

Your suggestion wouldn't protect against a sniffer on the smart card data lines unfortunately.

Cheers

[Bjorn Wielens]

Option two is probably logistically the simplest. It guarantees original software. As for the hardware, we could just post some high quality reference photos on the mp website for the user to perform a physical inspection for modifications or parasite circuitry...?

Bjorn

--

[Andrew]

I like option 2 also, but you'll need to add a disclaimer. Something along the lines of, not my fault if you install the screen upsidedown ;)

Though I can't help but think there should be a way of validating the devices using something soon to diffie-hellman or some such. The problem there, is that it has to be customized for for device

[Jesse Vallaro]

Right a hardware sniffer on those lines even if the firmware was valid and passed a key exchange wouldn't be detected. Makes sense.

--
~Jesse

From: mathieu...@gmail.com Sent: Friday, March 27, 2015 8:20 AM To: Jesse Vallaro Cc: mooltipass; Günther Hutzl

Subject: Re: [mooltipass] [Feedback request] Making sure the shipped device hasn't been tampered with during transport

[Evan B]

I was just about to say something along these lines. It's the only way I can see where option #2 will work any better than just shipping the thing sealed up, unless the enclosure was transparent or something.

On Mar 27, 2015 8:23 AM, "Bjorn Wielens" <vinta...@gmail.com> wrote:

[banj...@gmail.com]

Shipping with programming pins that exposed, wouldn't that make it too easy to install a corrupt firmware? Option #2 is of course the easiest way to detect hardware changed (as long as there is something to check up against) but this essentially requires every backer to reprogram the MP, no?

On Fri, Mar 27, 2015 at 11:22 AM, mathieu...@gmail.com <mathieu...@gmail.com> wrote:

--

[mathieu...@gmail.com]

Hello all,

Sniffed data could be sent via rf as well ;).
The only way to safely perform a device authentication would be to implement a challenge response routine on the device itself... Don't trust the computer!

[mathieu...@gmail.com]

Well copying the mechanical design isn't hard as well...

[Frank Katzenberger]

Serialized anti-tamper sticker over the seam. Reproduction of the label will take too long and will raise red flags for shipping time.

[Noah A]

My understanding was that the glue made the case tamper-evident. Is that not the case?

[Frank Katzenberger]

Two factor that can be verified via the web..

Serialized frangable label for the device
http://www.novavisioninc.com/pages/prd_security_labels.html

Shipping serialized package label:
http://m.uline.com/h5/r/www.uline.com/BL_3093/Security-Strips-on-a-Roll?keywords=

[Chris Hood]

I think that a simple anti tamper sticker over the openings of the box would be the simplest and not require that the user update firmware. The user would get a production ready device out of the box which would be a better customer experience.

Chris

Chris Hood
chris...@gmail.com
RHCE (RedHat Certified Engineer)
RHCVA (RedHat Certified Virtualization Administrator)
RHCDS (RedHat Certified Data Center Specialist)
C|EH (Certified Ethical Hacker)

[mathieu...@gmail.com]

So here's my PC based suggestion.

Taking into account that:

- direct access to the microcontroller eeprom isn't possible, even using a programmer (fuses are set this way)

- the device will take less than 4 years to arrive (aha)

Suggestion:

- store a unique 128bits key per device

- to gain access to the device UID this particular key needs to be showed

- a 3 seconds delay is added before checking the presented key

- half time brute force = 3*2^128 = 4*10^32 months

- key & uid needs to be requested to the mooltipass team once the device is received

- user checks the UID

... Does that make sense?

About RF sniffer.... in that case a seal would work... though they can be copied as well... so I'm still in favor physical checking.

Cheers

--

[Andrew Bovill]

I like this idea a lot, this way, for people who don't care, whatever,
just use the device. But for those that do, there is a non-spoofable way
to ensure that your mooltipass is running the proper software.

> <https://www.youtube.com/watch?v=X9gxmtwLPsw>) to allow the

> backer to reprogram the main microcontroller with the firmware
> downloaded from our repository.
>
> What do you think?
> Mathieu & the dev team
>
> --
> You received this message because you are subscribed to the Google
> Groups "mooltipass" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to mooltipass+...@googlegroups.com

> <mailto:mooltipass+...@googlegroups.com>.

> To post to this group, send email to moolt...@googlegroups.com

> <mailto:moolt...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/mooltipass.
> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "mooltipass" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mooltipass+...@googlegroups.com

> <mailto:mooltipass+...@googlegroups.com>.

> To post to this group, send email to moolt...@googlegroups.com

> <mailto:moolt...@googlegroups.com>.

[Richard Johnson]

Why not use a unique key chip? A lot of companies secure products with that all the time. The device boots up, reads the ID, phones home,  if valid responds "secure" if not, warns user. 

Richard Johnson

RJ Consulting - Making concepts reality

(234) - 206 - 0288

rjconsult.net

University of Akron

To unsubscribe from this group and stop receiving emails from it, send an email to mooltipass+...@googlegroups.com.
To post to this group, send email to moolt...@googlegroups.com.

[Kaspar Emanuel]

On 27 March 2015 at 13:54, mathieu...@gmail.com <mathieu...@gmail.com> wrote:

- direct access to the microcontroller eeprom isn't possible, even using a programmer (fuses are set this way)

Is there an option to disable this for people that are interested in hacking the device?

[mathieu...@gmail.com]

this can be disabled by erasing the chip (flash + eeprom)

[Charles Engen]

I like Mathieu's second idea:

The PC based suggestion:

Taking into account that:

- direct access to the microcontroller eeprom isn't possible, even using a programmer (fuses are set this way)

- the device will take less than 4 years to arrive (aha)

Suggestion:

- store a unique 128bits key per device

- to gain access to the device UID this particular key needs to be showed

- a 3 seconds delay is added before checking the presented key

- half time brute force = 3*2^128 = 4*10^32 months

- key & uid needs to be requested to the mooltipass team once the device is received

- user checks the UID

And want to acknowledge Richard Johnson's unique key chip....

- Charlie

[mathieu...@gmail.com]

Sorry I didn't answer you Richard: my suggestion actually implements the same functionality.

[Don Fanning]

I would vote for 2 - you could also put registered tamper proof security stickers over some components as well.  I think this would be the best way taking into account the mass production of devices.  

[Johnathan Clarke]

Option 3

Seal the device.  Make it similar to the iron key. The device is filled with a reason that basicly requires you to destroy the pcb to open it. That is the only way you can be sure of no physical tampering.
It will then mean you need to mod your firmware loading to make or easier. So that the end user can flash it when they receive it. Or
Again go down the path of iron key and require a pub/private key combo to unlock the device first time with a key you create at manufacturing.  The software then destroy this key and requires a new one to be set up. And used. Even if it's only for firmware changes?

Hardware security suxs it's hard and really unless you actually go to your factory. And pick up the device you can't be 100% sure.

[mathieu...@gmail.com]

Seal the device.  Make it similar to the iron key. The device is filled with a reason that basicly requires you to destroy the pcb to open it. That is the only way you can be sure of no physical tampering.

>> that indeed prevents physical tampering but it will fill the arduino connectors holes.... We could also imagine a skilled person dissolving the resin and unsoldering/resoldering the main microcontroller on another PCB!

Again go down the path of iron key and require a pub/private key combo to unlock the device first time with a key you create at manufacturing

>> my suggestion is a bit similar to that approach.

Hardware security suxs it's hard and really unless you actually go to your factory. And pick up the device you can't be 100% sure.

>> can't agree more!

[Charles Engen]

Sounds like iron key is epoxy... I have worked with this stuff,  it's weird and kinda nasty,  but works sort of...

I know I only have one equal vote to everyone else...  But I really like Mathieu 's 3 idea above that incorporates Richard' s method.

No method will ever be perfect,  it seems the  best way to go,  with the balance / trade offs David brings up.

Charlie

[Doug Young]

Iron key uses potting

--

[Charles Engen]

potting is the same as epoxy potting as far as I know

[Bjorn Wielens]

Potting is the process of encasing your board... it can be done with anything, really.

Epoxy, acrylic, silicone, etc. depending on your needs.

[Charles Engen]

Thanks Bjorn,

I have only done epoxy potting with opaic black epoxy that doesn't show anything for electronics.  I am sure you can X-ray or do something to see board traces, components, what have you.... And I also have drilled into things to reverse engineer them as Mathieu points out.  We are never going to please everyone 100% on this topic....

[Richard Johnson]

Agreed, you have to draw the line some where. It is like everything else, if some one wants to get into it, they will. ( ex: safes)

--

[Bjorn Wielens]

Much like cryptography... the goal isn't to make it impossible, but just to make it sufficiently impractical as an attack vector. :)

[Frank Katzenberger]

Here is my thought before it spirals too far away. 

I would suggest that a sealed shipping box with a serialized security label is all that is needed for the majority of backers.  If additional features are required, I would suggest that a separate contribution/charge be collected for those that need it.  Level 2 could include a serialized security label could seal the unit.  Level 3 could include the unique key (idea #2 is someone's above email.)  Because these are additional touch services, I would address it as $5 per shipment for level 2 and $10 per shipment for level 3.  Part of the reason for the cost will be to cover the label supplies, documenting them in a way that will be accessible by only the user when needed. Also note that this is per shipment cost, not per unit.  So if you have 2 units, the cost covers both.

Thanks,

Frank

Frank