Is there a process for secure firmware install/upgrade for device made offshore?

On 6/29/17 1:44 PM, Dave Nadler wrote:
> On Thursday, June 29, 2017 at 10:11:19 AM UTC-4, Boudewijn Dijkstra wrote:
>> https://www.segger.com/products/production/flasher/models/flasher-secure/
> 
> Would it not be easy to build a hardware gadget that logs the programming
> bit-stream at the target side of this programmer?
> 

One FPGA vendor that I have been using, Microsemi, actually sends 
encrypted programming files to the chip, and there is decryption 
hardware built into the chip, so no unencrypted data to sniff.

The chips come with a generic Microsemi key built in, and the tool by 
defaults encrypts to that key. You can also load yoour own private key 
into the chip, and encrypt the data to it, so only units which you have 
put you key into can use that data, and you can lock the device so you 
need to know the private key to even connect with a programmer/debugger.

There is also a unique serial number in each device, and you can include 
in the encrypted bit stream instructions that only a given device is to 
accept the bit stream. They then sell a special programmer that you can 
make your contract manufacturer use that accepts a file that has been 
encrypted with instructions of how many copies this file is allowed to 
make, and doing some accounting over the Internet, allows them to make 
exactly that many copies, getting the chips serial number, verifying 
permission over the Internet, and then encrypting for THAT particular 
device and programming. (The programmer using a secure processor so any 
decrypted bit patterns only exist inside the chip, so not accessible 
without breaking the encryption.

Op Thu, 29 Jun 2017 19:44:41 +0200 schreef Dave Nadler <drn@nadler.com>:
> On Thursday, June 29, 2017 at 10:11:19 AM UTC-4, Boudewijn Dijkstra  
> wrote:
>> https://www.segger.com/products/production/flasher/models/flasher-secure/
>
> Would it not be easy to build a hardware gadget that logs the programming
> bit-stream at the target side of this programmer?

Sure. But suppose that the image contains a cryptographic signature of the  
program code *and* the device's unique ID. And the program checks the  
signature before booting the application.


-- 
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

Op Fri, 30 Jun 2017 05:22:08 +0200 schreef <jhnlmn@gmail.com>:
> On Thursday, June 29, 2017 at 10:44:48 AM UTC-7, Dave Nadler wrote:
>> On Thursday, June 29, 2017 at 10:11:19 AM UTC-4, Boudewijn Dijkstra  
>> wrote:
>> >  
>> https://www.segger.com/products/production/flasher/models/flasher-secure/
>>
>> Would it not be easy to build a hardware gadget that logs the  
>> programming
>> bit-stream at the target side of this programmer?
>
> The details about this "Flasher secure" are very scarce,
> Flasher manual does not mention it at all.

Yeah, it's quite a new product, documentation is lagging a bit.

> This seem to be the most detailed explanation:
> http://www.embedded.com/electronics-blogs/max-unleashed-and-unfettered/4458187/Secure-the-off-site-production-programming-of-your-embedded-products
>
> It appears that they do nothing to prevent JTAG sniffing.

Just sniffing may not instantly make cloning possible. See my reply to  
Dave Nadler.

> And they cannot, theoretically, do anything without some support from  
> the chip maker (decryption on the chip itself).

I've heard that they're talking to ST and possibly others about secure  
JTAG/SWD.

> What is interesting is this "Flasher SECURE reads the UID from the  
> device".
> How? Which chips are supported? Is it a standard feature?

Lots of newish 32-bit devices have a UID register. Otherwise, you can  
usually generate a good-enough fingerprint from the SRAM reset state.



-- 
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

> Boudewijn Dijkstra
> Sure. But suppose that the image contains a cryptographic signature of the 
> program code *and* the device's unique ID. And the program checks the  
> signature before booting the application.

No, remember, until secure program is installed we cannot trust any pre-existing program in flash.
JTAG must wipe out entire flash and RAM before installing a secure program.

> Richard Damon
> One FPGA vendor that I have been using, Microsemi, actually sends
> encrypted programming files to the chip, and there is decryption
> hardware built into the chip, so no unencrypted data to sniff.
> The chips come with a generic Microsemi key built in

This seem to be the only solution.
I guess it will take several more years until most chip makers adopt this practice.
And then there still will be a risk that they will not hide the secret key on die well enough.
If the secret key is discovered, then entire batch of devices with the same key will be compromised.

Op Sat, 01 Jul 2017 02:11:44 +0200 schreef <jhnlmn@gmail.com>:
>> Boudewijn Dijkstra
>> Sure. But suppose that the image contains a cryptographic signature of  
>> the program code *and* the device's unique ID. And the program checks 
>> the signature before booting the application.
>
> No, remember, until secure program is installed we cannot trust any  
> pre-existing program in flash.
> JTAG must wipe out entire flash and RAM before installing a secure  
> program.

I meant that the program would check its own signature. It can still be  
reverse engineered and patched to skip the checks, but this can be made  
arbitrarily difficult.


-- 
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

> I meant that the program would check its own signature. 
> It can still be reverse engineered and patched to skip the checks, but this can be made 
arbitrarily difficult.

Please, explain.
As far as I can see, if a program can be both disassembled and patched (which unencrypted JTAG allows),
then anything is possible (and trivial), including skipping the check entirely or replacing the signature.

Op Mon, 03 Jul 2017 19:16:32 +0200 schreef <jhnlmn@gmail.com>:
>> I meant that the program would check its own signature.
>> It can still be reverse engineered and patched to skip the checks, but  
>> this can be made arbitrarily difficult.
>
> Please, explain.
> As far as I can see, if a program can be both disassembled and patched  
> (which unencrypted JTAG allows),
> then anything is possible (and trivial), including skipping the check  
> entirely or replacing the signature.

If we're talking about a connected device, then a trusted external agent
could verify the signature. Preventing or faking this is non-trivial. But
let's assume a non-connected device.

Skipping the check could be made non-trivial by obfuscation techniques, I
guess.

Replacing the flash signature by your own is of course prohibitively
difficult when an adequate cryptographic algorithm is used. Replacing the
signature calculation algorithm by a function that just copies the known
flash signature is indeed trivial. However, if the signature would be
calculated by some peripheral when writing flash and could only be
compared, and not read out, then copying would be impossible.





-- 
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

On 07/04/2017 07:32 AM, Boudewijn Dijkstra wrote:
> Op Mon, 03 Jul 2017 19:16:32 +0200 schreef <jhnlmn@gmail.com>:
>>> I meant that the program would check its own signature.
>>> It can still be reverse engineered and patched to skip the checks,
>>> but this can be made arbitrarily difficult.
>>
>> Please, explain.
>> As far as I can see, if a program can be both disassembled and patched
>> (which unencrypted JTAG allows),
>> then anything is possible (and trivial), including skipping the check
>> entirely or replacing the signature.
>
> If we're talking about a connected device, then a trusted external agent
> could verify the signature. Preventing or faking this is non-trivial. But
> let's assume a non-connected device.
>
> Skipping the check could be made non-trivial by obfuscation techniques, I
> guess.
>
> Replacing the flash signature by your own is of course prohibitively
> difficult when an adequate cryptographic algorithm is used. Replacing the
> signature calculation algorithm by a function that just copies the known
> flash signature is indeed trivial. However, if the signature would be
> calculated by some peripheral when writing flash and could only be
> compared, and not read out, then copying would be impossible.

Such as a TPM chip.

Cheers

Phil Hobbs


-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

> If we're talking about a connected device, then a trusted external agent could verify the signature

I can only imagine the following algo:
1. If there is a trusted connection (without man in the middle, etc)
2. You have trusted person on one end of this connection and firmware on another
3. Then trusted person can send a random key to the firmware
4. Firmware encrypts its entire flash and makes a hash and returns hash to the trusted person
5. Trusted person compares the hash with a hash calculated with a known good copy of firmware
If they are equal, then you do not know that firmware was not tampered with.
But having firmware verify its own signature, as you proposed earlier, is totally useless.

But if you have a trusted person and a trusted connection, then you can simply run regular JTAG and replace entire FW.
Again, my question was what to do if you have to install firmware on untrusted factory without a trusted connection.

> Skipping the check could be made non-trivial by obfuscation techniques, I guess

May be in a very large software, like Windows itself with gigabytes of code, but most firmwares are too small to hide anything.

> However, if the signature would be
> calculated by some peripheral when writing flash and could only be
> compared, and not read out, then copying would be impossible.
> Phil Hobbs:
> Such as a TPM chip.

Can you explain?
I read some texts about TPM chip and cannot understand how they can work with my FW.
For example:
http://whatis.techtarget.com/definition/trusted-platform-module-TP
"... protects the device against unauthorized firmware and software modification by hashing critical sections of firmware and software before they are executed. When the system attempts to connect to the network, the hashes are sent to a server that verifies that they match expected values."
Questions: is TPM a separate chip? How can it read firmware before execution? How can it work on devices without network access?

On 07/05/2017 05:14 PM, jhnlmn@gmail.com wrote:
>> If we're talking about a connected device, then a trusted external agent could verify the signature
>
> I can only imagine the following algo:
> 1. If there is a trusted connection (without man in the middle, etc)
> 2. You have trusted person on one end of this connection and firmware on another
> 3. Then trusted person can send a random key to the firmware
> 4. Firmware encrypts its entire flash and makes a hash and returns hash to the trusted person
> 5. Trusted person compares the hash with a hash calculated with a known good copy of firmware
> If they are equal, then you do not know that firmware was not tampered with.
> But having firmware verify its own signature, as you proposed earlier, is totally useless.
>
> But if you have a trusted person and a trusted connection, then you can simply run regular JTAG and replace entire FW.
> Again, my question was what to do if you have to install firmware on untrusted factory without a trusted connection.
>
>> Skipping the check could be made non-trivial by obfuscation techniques, I guess
>
> May be in a very large software, like Windows itself with gigabytes of code, but most firmwares are too small to hide anything.
>
>> However, if the signature would be
>> calculated by some peripheral when writing flash and could only be
>> compared, and not read out, then copying would be impossible.
>> Phil Hobbs:
>> Such as a TPM chip.
>
> Can you explain?
> I read some texts about TPM chip and cannot understand how they can work with my FW.
> For example:
> http://whatis.techtarget.com/definition/trusted-platform-module-TP
> "... protects the device against unauthorized firmware and software modification by hashing critical sections of firmware and software before they are executed. When the system attempts to connect to the network, the hashes are sent to a server that verifies that they match expected values."
> Questions: is TPM a separate chip? How can it read firmware before execution? How can it work on devices without network access?
>

I only know about it from the Qubes Anti-Evil-Maid defense, which 
presents the user with a known output from an unmodified /boot file 
system--it makes it possible for a human to recognize immediately when 
the unencrypted volume has changed.  _Somebody_ has to know what the 
signature is supposed to be.

Cheers

Phil Hobbs


-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net