Single wire protocol / bootloader ideas...

Go To Last Post
20 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Everyone

 

Now that you guys have schooled me on setting the protection bits for the bootloader so it can't update, er, uh, destroy itself, I've got some more thoughts...

 

I'm going to try my hand at building a secure bootloader that allows me to send someone an encrypted firmware file which is then sent to the device where its bootloader will decrypt and flash it.

 

One goal that I have is that as I rarely need to update firmware, I don't want to put any extra time or cost in soldering components to make it work.

 

I've been thinking about the various ways of delivering the encrypted firmware to the device.  You could use a PDIP-8 SPI EEPROM and pop it into a socket or even nicely placed holes if your PCB has the room.  Or use a sdcard if you don't mind soldering on a socket and the overhead of accessing a filesystem (I think it is clawson who has an excellent project example that does this).  Then I was thinking about using one of those PL2303 cheap cables somehow, but they are all 5V TTL level and my concern is that I need to support projects from 2.5V-5V.

 

Then I had the idea of using a very cheap PC programmer board.  I've already got USB stuff developed on the AVR and PC sides, so I could use a low cost ATMEGA8U2 along with a PC side application to provide the encrypted firmware from a file on a PC.  Minimal parts.  One nice thing is that it would be reusable and you could just email someone the encrypted file.

 

I read about a BSS138 based MOSFET that can be used for level translation and I am thinking of doing a 1 wire style (but not 1 wire) communication method.  The thought was that if I could use a single GPIO for communication that doesn't require any peripheral, it would be workable with most any AVR/project.  Probably with PCB something like this could be made for $5 or so.

 

With a single data line, the programmer would only need a ground and data line.  Both sides (device and programmer) would have two states - input with pullup OR output low.  The BSS138 I saw had two pullups, could the pullups in each AVR replace those two?  The programmer would be the higher voltage side (5V) and the device would be the lower voltage side (2.5V-5V).  As far as the protocol, the PC side would be the master MOST of the time, except during device startup.  Its bootloader would send out 3 bytes (cmd + crc) to see if a programmer is present and wait for a reply.  No reply = start device normally, Reply = stay in bootloader mode and wait for commands.  At that point the PC side would be the master and send commands to get versions, send the encrypted firmware file, etc.  The PC side app does not need to be privy to the page size of the device, its bootloader could know what it needs to do to decrypt and flash the data sent to it.  I've done some testing about how accurate I can sample a GPIO pin to figure out a low pulse width and I think it should be +/- 3 cycles using SBIC/RJMP to check for the pin change.  I also want to tolerate up to 20% clock error.  Bit 0 would be 10us, with error and +/-3 cycles this would be a range of 5-15us.  Bit 1 would be 25us would be 17-33us.  End of packet would be 50us or 37-63us.  So I would test for <16us = 0, <35us = 1, else end of packet.  With a 100us width, this would be a 10K bit rate and there will be plenty of cycles to shift the bits in from a GPIO.

 

For input on the programmer I can use ICP1 to get precision clock accurate captures of low pulse widths, but on devices I would want to have the option of using any GPIO so I would go with the SBIC/RJMP method.

For output I would just use timed sequences to send the 10us, 25us, or 50us pulses.

 

I would extend my crcsntool to support a tag in each section (application, bootloader) that contains the crc16, version, and possibly the serial number if serialized.  The SN would need to be in the bootloader tag if it was used to modify the encryption key so that each firmware file could be locked to a specific serial unit.

 

The PC app could have a check device button which queries if a device is connected and in bootloader mode.  A get status button could retrieve firmware versions, whether they have a valid crc, and a serial number if present.  A load firmware button could load a file for updating and an update button would do the update.

 

Thoughts, ideas, improvements?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alank2 wrote:
Then I was thinking about using one of those PL2303 cheap cables somehow, but they are all 5V TTL level and my concern is that I need to support projects from 2.5V-5V.
A PL2303 alternative is CH340 (CH341, etc)

Doesn't take much to have a dual-voltage capability (Schottky diode, pullup resistor)

https://github.com/OLIMEX/BB-CH340T/blob/master/PDFs/BB-CH340T-sch-export.pdf

via https://www.olimex.com/Products/Breadboarding/BB-CH340T/open-source-hardware

alank2 wrote:
I read about a BSS138 based MOSFET that can be used for level translation and I am thinking of doing a 1 wire style (but not 1 wire) communication method.
An alternative is a 1-bit level translator; could then interface with 1.8V AVR and 1.6V XMEGA AVR (BSS138 Vgs-th is 1.5V max at room temperature, more when cold)

An NFET advantage is its solution price is one-fourth that of a level translator.

http://www.onsemi.com/PowerSolutions/product.do?id=NLSX4401

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Then I had the idea of using a very cheap PC programmer board.

Then you lose end-to-end encryption.  The ATMEGA8U2 you use as a programmer will decrypt the payload and then program the target over ISP.  ISP is not encrypted.  Trivial to snoop the firmware during the update procedure.

 

Even if you use a '1-wire'-like link between the target and the 8U2, unless it too is encrypted, firmware is snoopable.

 

Or are you talking about using the 8U2 simply for a host interface to the target, and use an encrypted bootloader in the target...?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Wed. Oct 25, 2017 - 02:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've considered such strategies and ran into this quandary - who or what am I protecting against?

 

1. An unscrupulous person who would steal the software? If this is the case, then if it is delivered to the target unencrypted, at ANY point in the stream, all the thief has to do is connect it to a dummy target that collects the decrypted program. To prevent this, the decryption has to be within the bootloader inside the target. Care also needs to be taken to prevent the thief from interrupting the download just before the protective fuse bits are set. 

 

2. A person who would load bogus software into the target. Such bogus software MIGHT contain changes that cause the target to behave in unauthorized ways. Here, decryption is less the issue than validation though a decryption key could provide part, or maybe even all, of the authentication.

 

There are probably other scenarios where damage to you, damage to the customer, damage to others who rely on the device in some way, or damage to the hardware might occur.

 

Hope this helps

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

    Who is actually using a bootloader to update an 8 bit processor ?

    a) The end customer ? Not if it is a high volume product, unless the end product has a kinda permanent wireless connection to a PC for example or through an USB cable. The end customer of a high volume product would not bother to use your programmer. How many times did you update your TV remote control or your microwave oven firmware ?

    b) A manufacturer. If it is the same as the designer company, then everything happens in house so they do not need encryption. If it is a separate CM, and the CM wants to steal the firmware, they would copy the entire PC application you provide and use it as a whole.

 

    My opinion is that it is not worth the effort. You may find a customer here and there. Any added logistic regarding the serial number, encryption keys would discourage customers.

 

    Any way:

- using the internal pull up resistors will not allow you to get to fast because internal MOSFET capacities, cables

- you need a way to enter the bootloader. Reset pin would he a third connection. Power cycle ? Some customers would not be happy with it

- I would bit bang a UART having both Rx/Tx connected together (half duplex). Use 5 or 4 bit mode to allow more clock tolerance. Autobaud on mega8u. This would help you during development.

 

Cheers

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who is actually using a bootloader to update an 8 bit processor ?

People who don't test their stuff and send it out the door in a hurry? devil

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

angelu wrote:
Not if it is a high volume product, unless the end product has a kinda permanent wireless connection to a PC for example or through an USB cable.
Terminal servers is one way.

There appears to be some demand for remote update.

angelu wrote:
If it is a separate CM, and the CM wants to steal the firmware, they would copy the entire PC application you provide and use it as a whole.
An alternate way is to provide only BIT to the PCBA fab.

The manufacturer then assembles given the PCBA, tests, and performs partial or complete provisioning before shipping to the customers and/or operators.

angelu wrote:
Any added logistic regarding the serial number, encryption keys would discourage customers.
That's an issue with or without secure boot or an encrypted app.

embedded.com

Enhance system security with better data-at-rest encryption

March 24, 2012

(page 3 of 4)

https://www.embedded.com/design/safety-and-security/4369714/3/Enhance-system-security-with-better-data-at-rest-encryption

...

 

Remote key provisioning
We can consider two classes of unattended embedded systems: those that have a remote management network interface and those that do not.

...

 


ChiliPeppr Hardware Fiddle

http://chilipeppr.com/

Create Javascript software workspaces that talk to your hardware. Use one of our hugely popular workspaces or create your own by forking one you like.

...

 

Serial Port JSON Server

The heart of ChiliPeppr is a server that links your serial port devices and your host controller like a Raspberry Pi via websockets to your browser.

...

Plans and Features

 

PlatformIO Plus - Professional solutions for an awesome open source PlatformIO ecosystem.

Subscribe to PlatformIO Plus and help us to keep PlatformIO Open Source Project free, independent and alive!

...

 

PIO Delivery™. Automatic firmware updates!

http://platformio.org/pricing#solution-pio-delivery

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Worked on one dual 8-bit MPU system with UART bootloaders in ROM.

Updates were used for manufacturing BIT, (IIRC) small loads for safeties, and specific apps (modes, CBIT, etc)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

Or are you talking about using the 8U2 simply for a host interface to the target, and use an encrypted bootloader in the target...?

 

Yes, the 8u2 would be simply for the host interface.  Decryption would occur on the device itself completely inside its lockbits domain.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The NLSX4401 looks like it might be being retired.  I found this:

 

https://www.mouser.com/ProductDe...

 

My question for curiosity is how do these level translators work / what happens if both sides drive high at the same time?  Are they designed for open drain with a pullup?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

make your FW depending on something in the bootloader, so it's the bootloader that hold the secret code, and anyone can get the new FW, but it can only be used with your bootloader.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, the 8u2 would be simply for the host interface.  Decryption would occur on the device itself completely inside its lockbits domain.

Why not just implement a half-duplex USART rather than inventing your own open-drain bus?  You'll still need level translation, but no need to re-invent the wheel.  On targets which have a hardware USART, you can use the two pins TXD and RXD.  If you don't want to spend two pins, use RXD for both with hardware RX and bitbanged TX on the same pin.  With push-pull drive you can reach whatever speeds you like... not that an occasional bootload operation needs speed.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm with west coast Jim, what is the goal?

 

Is it to provide bug fixes to in-field equipment or to provide new features(functionallity)?

 

If the later, then sell the customer a new unit with improvements over his existing unit.

If the former then replace the unit with the bug fixes, at your expense!

 

Jim

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

make your FW depending on something in the bootloader, so it's the bootloader that hold the secret code, and anyone can get the new FW, but it can only be used with your bootloader.

 

Exactly!

 

joeymorin wrote:

Yes, the 8u2 would be simply for the host interface.  Decryption would occur on the device itself completely inside its lockbits domain.

Why not just implement a half-duplex USART rather than inventing your own open-drain bus?  You'll still need level translation, but no need to re-invent the wheel.  On targets which have a hardware USART, you can use the two pins TXD and RXD.  If you don't want to spend two pins, use RXD for both with hardware RX and bitbanged TX on the same pin.  With push-pull drive you can reach whatever speeds you like... not that an occasional bootload operation needs speed.

 

One reason is that I don't want to add any components to the device side at all, another is that I want as little requirement as possible (no hardware uart, no crystal) and a single gpio would do that.  I also want it to tolerate clock speed error, which doing one bit at a time is not fast, but it does accomplish that.  Update speed is not hugely important in this scenario, but I am looking to do around 10K bps.

 

ki0bk wrote:

I'm with west coast Jim, what is the goal?

Is it to provide bug fixes to in-field equipment or to provide new features(functionallity)?

If the later, then sell the customer a new unit with improvements over his existing unit.

If the former then replace the unit with the bug fixes, at your expense!

 

The goal is to have a way to update a product securely without them having to send it back.  I have been fortunate to not have had to deal with many bug fixes, but there is always that chance.  More often I want to introduce a new feature and sometimes the item is in another country where sending it back and forth is a pain.  My thought is, if there is a way to do this, why not implement it so it is an option.  It is a once done, I can use it on all projects/products type of thing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alank2 wrote:
The NLSX4401 looks like it might be being retired.
indecision it's not showing an EOL or NRND :

https://onsemi.secure.force.com/PCN/?pn=NLSX4401

Oh ... it's discontinued at Digi-Key :

https://www.digikey.com/products/en?keywords=nlsx4401

alank2 wrote:
I found this: [ADG3301]
Thanks!

Level translators are common in chip manufacturers' logic catalogs.

alank2 wrote:
My question for curiosity is how do these level translators work / what happens if both sides drive high at the same time?
The pass FET turns off during the transition from active pull-up to bus-hold pull-up.

alank2 wrote:
Are they designed for open drain with a pullup?
Yes though most have an internal bus hold pull-up.

Either evaluate the additional current source or locate a level translator without internal bus hold pull-ups (that may be a relative few)

Texas Instruments LSF level translators are a pass FET without pull-ups but one side is limited to 4.5V max for 5.5V max on other side (some Vgs is required)

http://www.ti.com/product/LSF0101/datasheet/detailed_description#SDLS9667912

 


https://www.mouser.com/search/ProductDetail.aspx?R=0virtualkey0virtualkeyNLSX4401MU1TCG

http://www.analog.com/en/products/interface-isolation/level-translators/adg3301.html

 

Edits: oh, Mouser

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Oct 25, 2017 - 04:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
If the former then replace the unit with the bug fixes, at your expense!
Embedded computers are literally embedded.

In one car, the ABS computer is underneath the front passenger's seat and the body computer is between the roof and the ceiling lining.

IIRC, all are connected by CAN which can open a can cheeky of worms (secure boot, secure identification, etc)

There are amazing videos of a CAN operator via their notebook PC removing control of the car from the car's operator.

IIRC, there's a relatively late model Jeep that had a network access vulnerability via the entertainment computer.

 

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I appreciate everyone's thoughts and comments - thanks!  I'll get started on it and see what I can do with it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One reason is that I don't want to add any components to the device side at all,

Why would you need to?  If using both TXD/RXD, just tie them together, no components required.  If using only RXD, still no components required.  In particular, if bitbanging TX on RXD, it can be done open-drain so there is no danger of driver contention.  If using TXD/RXD and desiring protection against driver contention, a single diode would be required.  Since you're controlling both ends, you can avoid driver contention programmatically and skip the diode.

 

another is that I want as little requirement as possible (no hardware uart, no crystal)

You don't >>need<< a hardware UART, you can bitbang the RX as well.  You also don't need a crystal on the target.  Your programmer can detect baud rate and adjust accordingly.

 

I also want it to tolerate clock speed error, which doing one bit at a time is not fast, but it does accomplish that.  Update speed is not hugely important in this scenario, but I am looking to do around 10K bps.

Understood.  FWIW I've also implemented a single-wire protocol similar to what you've described.  Currently uni-directional, although easily adapted to half-duplex.  Uses hardware USART for RX (because the target has one), and hardware or software TX as I've described.  Extremely wide tolerance for speed, on the order of +/-35%.  An entire frame is used to send 0xFE for a '1' bit and 0xF0 for '0' bit.  The receiver accepts 0xFC-0xFF as a '1', and anything else as a '0'.  Packet sync is done via a line break.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting topic.

IIRC the "old" forum had a sub-forum dedicated to encryption topics.

Recall, also, that the Xmega A series has a hardware encryption/decryption module.

 

I didn't see mentioned which chips you would like this system to be operational on.

The underlying question is what is the size of the Bootloader space you have available, throughout the full range of target chips for this project?

If you have a current Bootloader that you like, then you already know the amount of memory you have remaining within the Bootloader space for the additional features, (prior to optimizing for size the current Bootloader, and hopefully not breaking anything in the process!).

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
Recall, also, that the Xmega A series has a hardware encryption/decryption module.
A crypto engine can be attached to an MCU.

Microchip Technology Inc

Microchip

Secure AVR BLE IoT Node

http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=ATAVRBLE-IOT

The Secure AVR® BLE IoT Node incorporates an ATtiny1617 microcontroller, a fully-certified RN4871 Bluetooth® 4.2 Low Energy module, an ATECC508A CryptoAuthentication device and a 3-axis accelerometer with temperature sensor to demonstrate a complete solution for a typical IoT end node. The board is powered by USB or CR2032 coin cell via a jumper.

...

http://www.microchip.com/wwwproducts/en/attiny1617

http://www.microchip.com/wwwproducts/en/rn4871

http://www.microchip.com/wwwproducts/en/atecc508a

http://www.atmel.com/tools/CryptoAuthLib.aspx

 

"Dare to be naïve." - Buckminster Fuller