Attendees:
- Hannes Tschofenig
- Jaime Jiménez
- Tadahiko Ito
- Yohei Kaieda
- Yuichi Takita
- Dave Thaler
- Dan Petrie
- Emmanuel Baccelli
- Henk Birkholz
- Chris Inacio
- Laurence Lundblade
Twitter: #IETFHackathon & #IETF103
- Notes: https://gist.github.com/jaimejim/654654358e2c3da5ea19d3ba7cc3fdd1
- Slides: https://github.com/IETF-Hackathon/ietf103-project-presentations/blob/master/SUIT-hackathon103-presentation.pdf
- Hackathon Wiki: https://trac.ietf.org/trac/ietf/meeting/wiki/103hackathon
- Etherpad: https://etherpad.tools.ietf.org/p/FUIETF103
- SUIT IETF101: https://gist.github.com/jaimejim/3aa9c6e85e82a353c9fa90794c856d89
- SUIT IETF102: https://gist.github.com/jaimejim/82d53f97a9d011ef13c8750129b84cb1
- Poster info: http://jaimejim.github.io/docs/suit_poster.pdf
We have multiple points to touch:
- Hannes: I am trying to write a bootloader for the STM32F412ZG MCU. More information about the board can be found at https://os.mbed.com/platforms/Mbed-WiFi-BLE/
- Yohei, Tadahiko, Yuichi: Set up the Renesas RX231 environment with SUIT, provide a CBOR manifest example.
- Henk: Fix CDDL from the suit draft.
- Emmanuel: Help set up the RIOT environment in docker.
- Dan: Help set up the Mbed environment in docker.
- Jaime: The manifest information model has been updated and so should the example. The goal will be to have the new json manifest example and update the tools to encode, sign... Create and validate CBOR manifest.
Install Docker. Probably sudo apt-get install docker or download and install.
docker pull jaim/mbed-cli
To start a shell in the embed docker container:
docker run -it --entrypoint=/bin/bash jaim/mbed-cli:latest
In the mbed container shell:
Configure toolchain for target
mbed config --global ARM_PATH /usr/lib/arm-none-eabi
mbed config --global GCC_ARM_PATH /usr/bin
mbed config --global GCC_ARM /usr/lib/arm-none-eabi/lib
Download blinky example
mbed import mbed-os-example-blinky
Go to downloaded example directory
cd /mbed/mbed-os-example-blinky
Compile blinky example for K64F
mbed compile -m K64F -t GCC_ARM
In order to save the container after your work you can:
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9dacb8400cc7 jaim/mbed-cli:latest "/bin/bash" 3 minutes ago Up 3 minutes
$ docker commit c3f279d17e0a jaim/mbed-cli:suit
f5283438590d
$ docker images
REPOSITORY TAG ID CREATED SIZE
jaim/mbed-cli suit 7a900247ce52 13 minutes ago 2.2GB
jaim/mbed-cli latest ee30e6695c30 35 minutes ago 1.94GB
Then you can upload your own image to dockerhub too: https://ropenscilabs.github.io/r-docker-tutorial/04-Dockerhub.html
docker pull riot/riotbuild
git clone https://github.com/RIOT-OS/RIOT.git
Then in the RIOT directory
make BUILD_IN_DOCKER=1 -C examples/hello-world/ BOARD=frdm-k64f
For this to work on Mac, you will have to remove the line below (line 112) in makefiles/docker.inc.mk:
' -v /etc/localtime:/etc/localtime:ro \'
Brendan has been working on an updated version of the Python-based manifest generator. The code is available here: https://github.com/ARMmbed/suit-manifest-generator
Description: Current implementation of our microprosessor, Firmwares must be encrypted by AES key. That Key supposed to be deliver to devices with proprietary mechanism. We want to let devices to judge which key (on devices) correspond which firmware (on manifest). We, think it can be solved by adding “key id” on each payload of the manifest. So that we can identify key on device with keyid on manifest.
What we did: Create a new RX231 bootloader for SUIT. More Information about board can be found at https://www.renesas.com/sg/en/products/microcontrollers-microprocessors/rx/rx200/rx231.html Plan:
- Create a manifest file (which contain key id) for RX231.
Done, except key id. The manifest file version is draft-moran-suit-manifest-03.
- Manifest file (CBOR format).
0xa2 0x01 0x60 0x02 0xa5 0x01 0x01 0x02 0x02 0x03 0xa1 0x01 0x82 0x82 0x01 0x50
0x63 0x38 0xe6 0x23 0x71 0xf7 0x52 0xa3 0xa1 0xd0 0xf8 0x6e 0x99 0xdf 0x86 0x77
0x82 0x02 0x50 0x4b 0x0f 0xee 0x5e 0x7f 0x09 0x57 0x22 0xb1 0xa4 0x96 0x00 0x69
0x2c 0x4a 0x95 0x05 0x81 0xa3 0x01 0x81 0x41 0x00 0x02 0x1a 0x00 0x0a 0x8c 0x9a
0x03 0x84 0x44 0xa1 0x01 0x18 0x29 0xa0 0x60 0x58 0x20 0xfa 0xfd 0xee 0xd5 0x07
0x06 0xc5 0xfd 0x25 0xd1 0xac 0xdb 0xdb 0x72 0xbe 0x29 0x33 0x1a 0xa8 0x97 0x2a
0x93 0xa3 0x92 0xec 0xbc 0x87 0xef 0x67 0xd9 0x0f 0x63 0x06 0xa1 0x01 0x81 0xa2
0x01 0x81 0x41 0x00 0x02 0x81 0xa2 0x01 0x82 0x01 0x01 0x03 0x82 0x00 0x76 0x68
0x74 0x74 0x70 0x3a 0x2f 0x2f 0x66 0x6f 0x6f 0x2e 0x62 0x61 0x72 0x2f 0x62 0x61
0x7a 0x2e 0x62 0x69 0x6e
- Manifest file (JSON format for python dictionary and, Same semantics as above).
1 : "", # authenticationWrapper
2 : { # manifest
1 : 1, # manifestVersion
2 : 2, # sequence
3 : { # preInstall
1 : [ # preConditions
[1, b'\x63\x38\xe6\x23\x71\xf7\x52\xa3\xa1\xd0\xf8\x6e\x99\xdf\x86\x77'], # vendorId
[2, b'\x4b\x0f\xee\x5e\x7f\x09\x57\x22\xb1\xa4\x96\x00\x69\x2c\x4a\x95'] # classId
]
},
5 : [{ # payloads
1 : [b'\x00'], # payloadComponent
2 : 691354, # payloadSize
3 : [ # payloadDigest
b'\xa1\x01\x18\x29', # protected
{}, # unprotected
"", # paylod
b'\xfa\xfd\xee\xd5\x07\x06\xc5\xfd\x25\xd1\xac\xdb\xdb\x72\xbe\x29\x33\x1a\xa8\x97\x2a\x93\xa3\x92\xec\xbc\x87\xef\x67\xd9\x0f\x63' # tag
]
}],
6 : { # install
1 : [{ # payloadInstallInfos
1 : [b'\x00'], # component
2 : [{ # processors
1 : [1,1], # id
3 : [ 0, "http://foo.bar/baz.bin"] # inputs
}]
}]
}
}
-
Create a bootloader program with below three steps.
- Secure boot and, Install keys.
Done
- Check a Manifest file on bootloader. ( and Check if the set of Firmware, Keyfile, and Manifest is valid.)
Success to parse the manifest file (CBOR format) on bootloader. Put the manifest file on the ROM.
Concern:
It should be fine to note key id for each payload, but... if different vender happen to use same key id (i.e. "kid" : "AES128GCM") and collude, devices need to solve that.
it might be bad idea to use COSE digest instead of kid First, we thought It might be nice to store key on devices as COSE object, and minifest generator put COSE digest of that COSE object, on manifest. So that we can declare policy and usage of that keys. However, (it is depending on how to calculate COSE digest, but if we calculate with hash function), we noticed that it might be but idea. We believe that hash value of that cose object is close to hash value of AES key, and it should be keep secret (should not written in manifest).
https://github.com/cose-wg/Examples
There have been quite a lot of changes in moran-suit-manifest https://tools.ietf.org/rfcdiff?url2=draft-moran-suit-manifest-03.txt
We take out the cddl (https://tools.ietf.org/id/draft-moran-suit-manifest-03.html#rfc.section.8)
brew install ruby
hash -r
gem install cddl
cddl manifest03.cddl json-generate > m03.json
Note: Since the original CDDL was not correct we ignored the possibility of auto-generating a manifest file in JSON and define it manually instead. The other examples in the draft are wrong too. Tools needed:
pip3 install cbor
gem install cddl
The CBOR Diagnostic example is: https://github.com/jaimejim/suit-manifest-generator/blob/master/suit103.cbordiag
Processor GPIO map
