Re: Image signatures

[aditi hilbert]

Marko,

That’s true :( 10s is very long!
Some perf numbers are here if you want some reference later on.
http://www.cryptopp.com/benchmarks.html 


thanks,
aditi

> On Apr 6, 2016, at 6:47 PM, marko kiiskila  wrote:
> 
> I added ECC224, as this should be equivalent to RSA 2048 security-wise.
> 
> It appears that with mbedTLS the ECC size is bigger though. 14k, to be exact.
> 
> I did not go through that rigorous of size reduction for this though, as ECC 
> signature
> verification takes much longer than with RSA.
> It takes ~10 seconds to verify image signature, which has a significant
> impact on bootup time :)
> 
> I can’t believe I forgot about this property of ECC. But it’s been few years 
> since I used it.
> 
>> On Apr 4, 2016, at 3:37 PM, Aditi  wrote:
>> 
>> EC operations would be significantly smaller. They key size equivalent to 
>> RSA 2048 but would be 256 bits in EC. So that could be another option.
>> 
>> Thanks,
>> Aditi
>> 
>> Sent from my iPhone
>> 
>>> On Apr 4, 2016, at 12:49 PM, marko kiiskila  wrote:
>>> 
>>> Hi,
>>> 
>>> I started work on signed images, and there’s few things I’m wondering how 
>>> to go about.
>>> 
>>> The way this would work is that you would start by creating a RSA key-pair 
>>> (2048 bits).
>>> 
>>> You’d sign the image by computing RSA signature over the image hash 
>>> (SHA256), and store
>>> it a TLV at the end of the image. Bootloader would be built with the public 
>>> key of this
>>> image signing key, and it would verify it before allowing the image to boot.
>>> 
>>> The impact of this on the bootloader is ~7k of additional text, so it’s use 
>>> should be optional.
>>> That comes from code to parse the public key and RSA itself. And the public 
>>> key itself.
>>> 
>>> The image header contains a flag that says that this image contains this 
>>> kind of signature,
>>> as well as the total length of all TLVs in the end. Image hash is computed 
>>> over this header.
>>> 
>>> Signature data itself is stored in PKCS 1.5 format.
>>> 
>>> I also added a keyid field, and you can use this to facilitate the use of 
>>> multiple image signing
>>> keys. You could use this to facilitate the use of image signing keys of 
>>> different security
>>> level. I.e. you would have a separate image signing key for building 
>>> ‘production’ builds as
>>> opposed to ‘development’ builds.
>>> 
>>> Production signing key would be stored somewhere safe with controlled 
>>> access, while
>>> development key could have more lax restrictions. Then you’d have different 
>>> bootloader
>>> versions, dev boot loaders would allow it to boot images that are signed 
>>> with production keys,
>>> or with development keys. Production boot loaders would only allow it to 
>>> boot images signed
>>> with production keys only.
>>> 
>>> This way you can do in-house development/QA using images signed with dev 
>>> keys, without
>>> having to worry about those images being bootable by products in the field.
>>> 
>>> On to my questions:
>>> 1) Any reviews of this code would be much appreciated! Bugs in this code 
>>> would be (very) bad.
>>> 2) How should this be incorporated into build system? Specifically, how to 
>>> control
>>> - whether bootloader expects signed images, and if so, whether it’s a dev 
>>> bootloader, or
>>> production bootloader?
>>> - where should the public key for bootloader be stored? Note that this 
>>> probably would be
>>> per-product specific.
>>> 
>>> Comments, suggestions are welcome
> 

Re: Rename newtmgr protocol

[Vipul Rahane]

I agree as well.

> On Apr 6, 2016, at 8:44 PM, "p...@wrada.com"  wrote:
> 
> I like the idea of having different names.  I think nmp is fine for the
> protocol.  
> 
>> On 4/6/16, 7:24 PM, "Christopher Collins"  wrote:
>> 
>> Hello all,
>> 
>> There are two things called "newtmgr":
>> 
>> 1. A simple command-response protocol used for interfacing with mynewt
>>  devices (the newtmgr server code is at core:libs/newtmgr).
>> 2. A CLI tool which communicates with mynewt devics via the newtmgr
>> protocol
>>  (newt:newtmgr).
>> 
>> I have had a hard time discussing both of these entities due to the
>> overloaded name.  In the interest of preventing an endless series of
>> "who's on first" fiascos, I propose we rename the name of the protocol.
>> 
>> I suggest we rename the protocol to: nmp.  I don't really care about the
>> name, though, as long as it is unique :).
>> 
>> Alternatively, the tool could be renamed, but I thought newtmgr sounds
>> more like a tool than a protocol.
>> 
>> Thanks,
>> Chris
> 

Re: Rename newtmgr protocol

[p...@wrada.com]

I like the idea of having different names.  I think nmp is fine for the
protocol.  

On 4/6/16, 7:24 PM, "Christopher Collins"  wrote:

>Hello all,
>
>There are two things called "newtmgr":
>
>1. A simple command-response protocol used for interfacing with mynewt
>   devices (the newtmgr server code is at core:libs/newtmgr).
>2. A CLI tool which communicates with mynewt devics via the newtmgr
>protocol
>   (newt:newtmgr).
>
>I have had a hard time discussing both of these entities due to the
>overloaded name.  In the interest of preventing an endless series of
>"who's on first" fiascos, I propose we rename the name of the protocol.
>
>I suggest we rename the protocol to: nmp.  I don't really care about the
>name, though, as long as it is unique :).
>
>Alternatively, the tool could be renamed, but I thought newtmgr sounds
>more like a tool than a protocol.
>
>Thanks,
>Chris

Rename newtmgr protocol

[Christopher Collins]

Hello all,

There are two things called "newtmgr":

1. A simple command-response protocol used for interfacing with mynewt
   devices (the newtmgr server code is at core:libs/newtmgr).
2. A CLI tool which communicates with mynewt devics via the newtmgr protocol
   (newt:newtmgr).

I have had a hard time discussing both of these entities due to the
overloaded name.  In the interest of preventing an endless series of
"who's on first" fiascos, I propose we rename the name of the protocol.

I suggest we rename the protocol to: nmp.  I don't really care about the
name, though, as long as it is unique :).

Alternatively, the tool could be renamed, but I thought newtmgr sounds
more like a tool than a protocol.

Thanks,
Chris

Re: hal_gpio_toggle() should return changed pin state

[p...@wrada.com]

Sound good to me 

> On Apr 6, 2016, at 3:10 PM, will sanfilippo  wrote:
> 
> Seems fine to me.
> 
> 
>> On Apr 6, 2016, at 1:45 PM, Vipul Rahane  wrote:
>> 
>> Hello,
>> 
>> Current definition: void hal_gpio_toggle() doesn’t return anything. 
>> Proposed definition: int hal_gpio_toggle(). I want to do this so that it 
>> returns the pins changed state. I would like to make this change so that we 
>> know what the gpio is actually set to.
>> 
>> Both ways we do hal_gpio_read(). Thoughts ?
>> 
>> Regards,
>> Vipul Rahane
> 

Re: Image signatures

[marko kiiskila]

I added ECC224, as this should be equivalent to RSA 2048 security-wise.

It appears that with mbedTLS the ECC size is bigger though. 14k, to be exact.

I did not go through that rigorous of size reduction for this though, as ECC 
signature
verification takes much longer than with RSA.
It takes ~10 seconds to verify image signature, which has a significant
impact on bootup time :)

I can’t believe I forgot about this property of ECC. But it’s been few years 
since I used it.

> On Apr 4, 2016, at 3:37 PM, Aditi  wrote:
> 
> EC operations would be significantly smaller. They key size equivalent to RSA 
> 2048 but would be 256 bits in EC. So that could be another option.
> 
> Thanks,
> Aditi
> 
> Sent from my iPhone
> 
>> On Apr 4, 2016, at 12:49 PM, marko kiiskila  wrote:
>> 
>> Hi,
>> 
>> I started work on signed images, and there’s few things I’m wondering how to 
>> go about.
>> 
>> The way this would work is that you would start by creating a RSA key-pair 
>> (2048 bits).
>> 
>> You’d sign the image by computing RSA signature over the image hash 
>> (SHA256), and store
>> it a TLV at the end of the image. Bootloader would be built with the public 
>> key of this
>> image signing key, and it would verify it before allowing the image to boot.
>> 
>> The impact of this on the bootloader is ~7k of additional text, so it’s use 
>> should be optional.
>> That comes from code to parse the public key and RSA itself. And the public 
>> key itself.
>> 
>> The image header contains a flag that says that this image contains this 
>> kind of signature,
>> as well as the total length of all TLVs in the end. Image hash is computed 
>> over this header.
>> 
>> Signature data itself is stored in PKCS 1.5 format.
>> 
>> I also added a keyid field, and you can use this to facilitate the use of 
>> multiple image signing
>> keys. You could use this to facilitate the use of image signing keys of 
>> different security
>> level. I.e. you would have a separate image signing key for building 
>> ‘production’ builds as
>> opposed to ‘development’ builds.
>> 
>> Production signing key would be stored somewhere safe with controlled 
>> access, while
>> development key could have more lax restrictions. Then you’d have different 
>> bootloader
>> versions, dev boot loaders would allow it to boot images that are signed 
>> with production keys,
>> or with development keys. Production boot loaders would only allow it to 
>> boot images signed
>> with production keys only.
>> 
>> This way you can do in-house development/QA using images signed with dev 
>> keys, without
>> having to worry about those images being bootable by products in the field.
>> 
>> On to my questions:
>> 1) Any reviews of this code would be much appreciated! Bugs in this code 
>> would be (very) bad.
>> 2) How should this be incorporated into build system? Specifically, how to 
>> control
>> - whether bootloader expects signed images, and if so, whether it’s a dev 
>> bootloader, or
>> production bootloader?
>> - where should the public key for bootloader be stored? Note that this 
>> probably would be
>> per-product specific.
>> 
>> Comments, suggestions are welcome

Re: hal_gpio_toggle() should return changed pin state

[will sanfilippo]

Seems fine to me.


> On Apr 6, 2016, at 1:45 PM, Vipul Rahane  wrote:
> 
> Hello,
> 
> Current definition: void hal_gpio_toggle() doesn’t return anything. 
> Proposed definition: int hal_gpio_toggle(). I want to do this so that it 
> returns the pins changed state. I would like to make this change so that we 
> know what the gpio is actually set to.
> 
> Both ways we do hal_gpio_read(). Thoughts ?
> 
> Regards,
> Vipul Rahane

hal_gpio_toggle() should return changed pin state

[Vipul Rahane]

Hello,

Current definition: void hal_gpio_toggle() doesn’t return anything. 
Proposed definition: int hal_gpio_toggle(). I want to do this so that it 
returns the pins changed state. I would like to make this change so that we 
know what the gpio is actually set to.

Both ways we do hal_gpio_read(). Thoughts ?

Regards,
Vipul Rahane

Re: [VOTE]: Committer status for Paul Dietrich and Neel Natu

[Christopher Collins]

On Tue, Apr 05, 2016 at 10:39:01PM -0700, aditi hilbert wrote:
> This is a call to vote on conferring committer status to the following
> two contributors. They have submitted several patches and entire
> modules via pull requests on Mynewt github mirrors on a variety of
> topics. 
> 
> [+1] Paul Dietrich
> [+1] Neel Natu
> 
> They have submitted the ICLA already. Voting will be open for 72 hours. 

Thanks,
Chris

Re: April board report for Mynewt

[Jim Jagielski]

+1

Thx!

> On Apr 6, 2016, at 1:33 AM, aditi hilbert  wrote:
> 
> Justin,
> 
> Thanks for the review. Here is the revised draft. I am trying to upload it to 
> the Apache site now.
> 
> I misspoke actually. Three new people started adding code via pull 
> requests/patches. We decided on the process to add committers but never 
> formally put the two largest contributors (committer candidates) to vote.  
> I’ll send out the formal request for vote.
> 
> thanks,
> aditi
> 
> ———
> 
> Mynewt 
> Mynewt is a real-time operating system for constrained embedded systems like 
> wearables, lightbulbs, locks and doorbells. It works on a variety of 32-bit 
> MCUs (microcontrollers), including ARM Cortex-M and MIPS architectures. 
> Mynewt has been incubating since 2015-10-20. 
> 
> Three most important issues to address in the move towards graduation: 
> 1. Make further releases capable of producing a downloadable RTOS image with 
> support for multiple peripherals and network connectivity. Do subsequent 
> releases to indicate thorough understanding, repeatability, and maturity of 
> process. 
> 2. Continue to develop and execute policies that enable project contributors 
> to achieve self-governance 
> 3. Expand community - attract new project contributors and users, grow 
> committer base 
> 
> Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware 
> of? 
> None 
> 
> How has the community developed since the last report? 
> 1. Healthy, active mailing lists with increasing numbers of subscribers
> 2. Continual outside interest by 3rd parties. Outreach via conferences, 
> exhibits, one on one meetings, beta testers, GSoC participation.
> 3. Vigorous discussions and implementation decisions via proposals and voting 
> on @dev mailing list.
> 
> How has the project developed since the last report? 
> 1. Releases:  Two releases so far - first on 22nd Feb, next on 18th March
>   - Identified and fixed license issues, regular process established to 
> check for license issues esp. with third party software
>   - Tagging process and release candidate naming process tested and used
>   - Voting process and timelines established and used
> 2. Documentation support: Several committers added documentation either 
> through direct git pushes or pull requests on github mirror.
> 3. Effort towards self governance: 
>   - Two releases completed successfully. 
>   - Two committer candidates going through voting for committer status 
> after meeting threshold of patch submissions.
> 
> Date of last release: 
> 18 March, 2016 
> 
> When were the last committers or PMC members elected? 
> At the start.
> 
> Signed-off-by: 
> [ ](mynewt) Sterling Hughes 
> [ ](mynewt) Jim Jagielski 
> [ ](mynewt) Justin Mclean 
> [ ](mynewt) Greg Stein 
> [ ](mynewt) P. Taylor Goetz 
> 
> Shepherd/Mentor notes: