Date   

Re: [Zephyr-devel] Working with flash on nrf52840

ashish.shukla@corvi.com <ashish.shukla@...>
 

It runs successfully. Thanks !


--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


On Fri, Jan 19, 2018 at 12:39 PM, Puzdrowski, Andrzej <Andrzej.Puzdrowski@...> wrote:

Add configuration CONFIG_MPU_ALLOW_FLASH_WRITE=y to the project (or select via Kconfig).

This should help.

 

Andrzej

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of ashish.shukla@...
Sent: Friday, January 19, 2018 7:09 AM
To: zephyr-devel@lists.zephyrproject.org; zephyr-users@lists.zephyrproject.org
Subject: [Zephyr-devel] Working with flash on nrf52840

 

Hello all !!

I'm working with /zephyr/samples/driver/soc_flash_nrf5. when I run this example, flash erase is successful,but it fails to write anything, resulting in error

 Data Access Violation

 Address : 0x40000

 

Changing the offset address, results in failure in flash erase itself. I guess it's something to do with offset address I'm working with. Can someone throw some light what's happening in case of nrf52840.

 

Has anyone succeeded in making it work? 


 

--

Warm regards,
Ashish Shukla

Jr. Embedded Engineer

Research & Development

 

Please consider the environment before printing this e-mail or its attachments.

 

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi

 



Re: [Zephyr-devel] Working with flash on nrf52840

Puzdrowski, Andrzej <Andrzej.Puzdrowski@...>
 

Add configuration CONFIG_MPU_ALLOW_FLASH_WRITE=y to the project (or select via Kconfig).

This should help.

 

Andrzej

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of ashish.shukla@...
Sent: Friday, January 19, 2018 7:09 AM
To: zephyr-devel@...; zephyr-users@...
Subject: [Zephyr-devel] Working with flash on nrf52840

 

Hello all !!

I'm working with /zephyr/samples/driver/soc_flash_nrf5. when I run this example, flash erase is successful,but it fails to write anything, resulting in error

 Data Access Violation

 Address : 0x40000

 

Changing the offset address, results in failure in flash erase itself. I guess it's something to do with offset address I'm working with. Can someone throw some light what's happening in case of nrf52840.

 

Has anyone succeeded in making it work? 


 

--

Warm regards,
Ashish Shukla

Jr. Embedded Engineer

Research & Development

 

Please consider the environment before printing this e-mail or its attachments.

 

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi

 


Working with flash on nrf52840

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hello all !!

I'm working with /zephyr/samples/driver/soc_flash_nrf5. when I run this example, flash erase is successful,but it fails to write anything, resulting in error

 Data Access Violation
 Address : 0x40000

Changing the offset address, results in failure in flash erase itself. I guess it's something to do with offset address I'm working with. Can someone throw some light what's happening in case of nrf52840.

Has anyone succeeded in making it work? 


--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


support for NFFS file system

Vikrant More <vikrant8051@...>
 

Hello World !!

Is Zephyr going to add support for NFFS file system in upcoming 1.11 (March 20148) release ?

What is current status of NFFS file system development ?
Could anybody explain me from Zephyr Core developer team ?

Thank You !! 


Re: understanding of #BluetoothMesh OOB authentication procedure #bluetoothmesh

Vikrant More <vikrant8051@...>
 

Hi Johan,

Many many thanks Johan, for your in detail explanation.

I don't want to use static public-private key pair for DEVICE & happy with current implementation.
It is inherently more secure since every time new pair get generated.

Now as per my understanding, it is only important to do authentication over OOB using randomly generated
(on every reset if DEVICE is in Unprovisioned state) 16-Bytes static-OOB.

OR

If I have to go with output-OOB or input-OOB but it will increase cost of BoM since we have to add NFC or small LCD etc. etc.
(Note that all budget smartphone doesn't have NFC feature)

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Second point is, I don't want to use Input-OOB & output-OOB.

By taking reference from your old reply, I have an idea to generate secret RANDOM 16-bytes static OOB using DEVICE MAC address
by executing some common vendor specific algorithm on both sides where nothing will get exchanged over OOB channel.

In case of nRF52840, we get DEVICE's MAC address by accessing oob.addr.a.val.


" Static OOB or No OOB

In cases where neither Input OOB or Output OOB are possible,

the provisioner and unprovisioned device may use either Static OOB authentication or No OOB authentication.

In this case, the provisioner and unprovisioned device each generate a random number and then proceed to the check confirmation value operation "


Now this is confusing, if I edit code as follow that means only static-OOB feature is working

static const struct bt_mesh_prov prov =
{
    .uuid = dev_uuid,

    .static_val = static_oob,  // <-- randomly generated after every reset
    .static_val_len=16,

    //.output_size = 4,
    //.output_actions = BT_MESH_BLINK | BT_MESH_BEEP | BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
    //.output_number = output_number,
    //.output_string = output_string,

    .complete = prov_complete,
    .reset = prov_reset,
};


And as per that link, if random no. is different for DEVICE & Provisioner then how they will authenticate each other

( assuming OOB channel is not at all in existence) ?

Is OOB channel is mandatory to exchange those 2 static-OOB ?

In case of #meshctl, it ask only for DEVICE's (16-bytes ) static-OOB & nothing provide from own side for DEVICE.

Is OOB channel/tunnel approx. mandatory concept of #BluetoothMesh ? 

Thank You !!

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


On Jan 17, 2018 2:15 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Vikrant,

On Tue, Jan 16, 2018, Vikrant More wrote:
> When I comment-out following lines as below
>
> static const struct bt_mesh_prov prov =
> {
>     .uuid = dev_uuid,
>
>
> * //.output_size = 4,    //.output_actions = BT_MESH_BLINK | BT_MESH_BEEP |
> BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
> //.output_number = output_number,*
>     .complete = prov_complete,
>     .reset = prov_reset,
> };
>
> , flowchart (5.4.2) follows path as per attached FlowChart_1.pdf. Am I
> right ?

Yes.

> & when I uncomment following lines as below
>
> static const struct bt_mesh_prov prov =
> {
>     .uuid = dev_uuid,
>
>
> * .output_size = 4,    .output_actions = BT_MESH_BLINK | BT_MESH_BEEP |
> BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
> .output_number = output_number,*
>     .complete = prov_complete,
>     .reset = prov_reset,
> };
>
> , flowchart follows path as per attached FlowChart_2.pdf. Am I right ?

Yes.


> DEVICE's Public key can be static or dynamic plus it can exchange over
> Bluetooth-Link or OOB. Am I right ?

Yes.

> As per current implementation, we are using *dynamic Public Key*
> *& *both sides public keys are get exchanged over Bluetooth-Link instead of
> OOB. Am I right ?

Yes.

> But when I want to use static Public-Private keys for DEVICE (provisioner
> may have dynamic pair), how & where to edit so that provisioner will
> understand that DEVICE has static public key ?

The provisioner doesn't really need to know if the key is static or
public. It just needs to know which key to use for the provisioning.

What the implementation is missing right now is a way to use a static
private-public keypair instead of a dynamically generated one. We would
probably need to introduce new Kconfig option and extra code to the
current ECDH implementation (in subsys/bluetooth/host/hci_ecc.c) to read
a pre-existing public key from some persistent location instead of
generating a new key pair.

> How provisioner will understand from where to received/read DEVICE
> public key out of *Bluetooth-Link* or *OOB* channel ?

I believe this is out of scope for the specification, since any OOB
channel is by definition something else than Bluetooth. In practice this
would then have to be a vendor-specific solution. There could e.g. be
hints in the advertsing data, or behind the optional URL in the
advertising data, as to what kind of OOB channel the unprovisioned node
wants to use.

> If public keys get exchanged over insecure channel, then what is
> significance of OOB tunnel over Bluetooth-Link ?

You might want to read up on how Diffie-Hellman key exchange works:
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

You essentially acheive confidentiality for the link with the peer
you've exchanged public keys with, but only through the OOB
authentication phase will you be able to authenticate that the peer
really is who you think it is.

Johan


Re: Emulating 2(or Multiple) Network interfaces in the same QEMU Machine

Michael Hope
 



On Tue, 16 Jan 2018 at 15:28 Juliano Siloto Assine <jsiloto@...> wrote:
Thanks Michael, I was able to reproduce on my board. I was having some trouble because there is only one UART on the nrf52 DK so I couldn't access the console to see what was going on.
I agree with Paul, it took me some reading about slip and ppp, tun/tap etc, to figure things out, which is not bad, but a sample in the repo would have been really helpful.

Just a few more questions:

CONFIG_UART_PIPE is automatically selected when the SLIP driver is selected.  See drivers/net/Kconfig for more.

2 - Using the http_server example, tunslip6 -v2 works, but -v4 doesn't, there may be a bug there
3- http_server example works of firefox but not on chrome.

Yeah, I might be seeing similar - could you log a bug?  What I see with wget on the http_server example is:

```
$ wget -O - http://192.168.1.233/
--2018-01-17 21:17:32--  http://192.168.1.233/
Connecting to 192.168.1.233:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘STDOUT’

-                         [<=>                       ]       0  --.-KB/s               <html>
  <head>
    <meta charset="UTF-8">
    <title>Zephyr HTTP server sample</title>
  </head>

  <body>
    <div>
      <p>It works!</p>
    </div>
  </body>
</html>
-                         [ <=>                      ]     170  --.-KB/s    in 0s     

2018-01-17 21:17:33 (9,03 MB/s) - Read error at byte 170 (Success).Retrying.
```

The interesting bit is the final 'read error - success' which puts wget into a retry loop.

-- Michael


2018-01-13 8:55 GMT-02:00 Paul Sokolovsky <paul.sokolovsky@...>:
Hello Michael,

On Fri, 12 Jan 2018 19:58:12 +0000
Michael Hope <michaelh@...> wrote:

> It turns out that samples/net/http_server already works fine :)
>
> I had to shrink the buffer count to fit on the 32 KiB on the Arduino
> Zero though.

Sure, existing samples should work, that's the whole idea. As soon as
you enable bunch of options (and outsider would say "obscure options"),
and run stuff on a host ("obscure stuff", an outsider would say; what
do we do to run SLIP on Linux nowadays? Is it still something simple as
slirp, or it was subsumed by pppd and you need to dig into its obscure
option to make it run, jungling to not affect system-wide setup and
not get an option conflict?).

Effectively, a known working configuration and README describing the
full setup is what would comprise a SLIP sample, the code is definitely
there. So, please don't discount it as something not useful and not
worth a hacking pleasure ;-).

>
> -- Michael
>
> On Thu, 11 Jan 2018 at 00:15 Paul Sokolovsky
> <paul.sokolovsky@...> wrote:
>
> > Hello Michael,
> >
> > On Mon, 08 Jan 2018 18:35:48 +0000
> > Michael Hope <michaelh@...> wrote:
> >
> > []
> >
> > > > 2. If I have a physical device, can I emulate a networking
> > > > connection using UART in the same fashion?
> > > >
> > >
> > > Yip, this works well.  One of the first things I did when I
> > > picked up Zephyr was configure SLIP and ping the board :)
> >
> > Perhaps, you should contribute a sample application to samples/ for
> > that ;-).

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Security of Mesh Network

Johan Hedberg
 

Hi Ashish,

On Wed, Jan 17, 2018, ashish.shukla@corvi.com wrote:
As you replied to Vikrant

"I think using public key in-band and an OOB mechanism
during the authentication stage would also help prevent MITM attacks
(though only a 128-bit randomly generated Static OOB value should be
considered as "high" security level)."

what if I use in-band mechanism to exchange public keys and during
authentication stage, I changed output size of OOB number to 1 and blinked
LED on the board to the same number of times. This number can be entered
into provisioner to generate ConfirmationValue.

Out of these two methods
1. 128-bit randomly generated Static OOB
2. and one I mentioned above

Which one would be more secure?
The one with higher entropy. In the example you gave it'd be some 3 bits
vs 128 bits. The main reason the Input & Output OOB mechanisms are less
secure is that there's too low entropy for the OOB data, i.e. it's too
easy to brute-force/guess it.

Johan


Re: understanding of #BluetoothMesh OOB authentication procedure #bluetoothmesh

Johan Hedberg
 

Hi Vikrant,

On Tue, Jan 16, 2018, Vikrant More wrote:
When I comment-out following lines as below

static const struct bt_mesh_prov prov =
{
.uuid = dev_uuid,


* //.output_size = 4, //.output_actions = BT_MESH_BLINK | BT_MESH_BEEP |
BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
//.output_number = output_number,*
.complete = prov_complete,
.reset = prov_reset,
};

, flowchart (5.4.2) follows path as per attached FlowChart_1.pdf. Am I
right ?
Yes.

& when I uncomment following lines as below

static const struct bt_mesh_prov prov =
{
.uuid = dev_uuid,


* .output_size = 4, .output_actions = BT_MESH_BLINK | BT_MESH_BEEP |
BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
.output_number = output_number,*
.complete = prov_complete,
.reset = prov_reset,
};

, flowchart follows path as per attached FlowChart_2.pdf. Am I right ?
Yes.


DEVICE's Public key can be static or dynamic plus it can exchange over
Bluetooth-Link or OOB. Am I right ?
Yes.

As per current implementation, we are using *dynamic Public Key*
*& *both sides public keys are get exchanged over Bluetooth-Link instead of
OOB. Am I right ?
Yes.

But when I want to use static Public-Private keys for DEVICE (provisioner
may have dynamic pair), how & where to edit so that provisioner will
understand that DEVICE has static public key ?
The provisioner doesn't really need to know if the key is static or
public. It just needs to know which key to use for the provisioning.

What the implementation is missing right now is a way to use a static
private-public keypair instead of a dynamically generated one. We would
probably need to introduce new Kconfig option and extra code to the
current ECDH implementation (in subsys/bluetooth/host/hci_ecc.c) to read
a pre-existing public key from some persistent location instead of
generating a new key pair.

How provisioner will understand from where to received/read DEVICE
public key out of *Bluetooth-Link* or *OOB* channel ?
I believe this is out of scope for the specification, since any OOB
channel is by definition something else than Bluetooth. In practice this
would then have to be a vendor-specific solution. There could e.g. be
hints in the advertsing data, or behind the optional URL in the
advertising data, as to what kind of OOB channel the unprovisioned node
wants to use.

If public keys get exchanged over insecure channel, then what is
significance of OOB tunnel over Bluetooth-Link ?
You might want to read up on how Diffie-Hellman key exchange works:
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

You essentially acheive confidentiality for the link with the peer
you've exchanged public keys with, but only through the OOB
authentication phase will you be able to authenticate that the peer
really is who you think it is.

Johan


Re: NFC Library

Erwan Gouriou
 

On 17 January 2018 at 08:33, Erwan Gouriou <erwan.gouriou@...> wrote:
Ok, Thanks Carles.
So let me create an issue as a start, and we'll build on that.

Regards
Erwan

On 16 January 2018 at 14:51, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Erwan,

 

We have not looked into it yet, but there would definitely be interest from us since many of our ICs support NFC. We currently ship a binary blob in our proprietary SDK, so that is not an option.

 

Regards,

 

Carles

 

From: zephyr-users-bounces@...hyrproject.org [mailto:zephyr-users-bounces@lists.zephyrproject.org] On Behalf Of Erwan Gouriou
Sent: 16 January 2018 14:44
To: Zephyr-users@...ct.org
Subject: [Zephyr-users] NFC Library

 

Hi all,

Does anyone have ever looked to a NFC library that could be integrated into Zephyr?

Would there be any interest?

 

Thanks

Erwan

 




Re: NFC Library

Erwan Gouriou
 

Ok, Thanks Carles.
So let me create an issue as a start, and we'll build on that.

Regards
Erwan

On 16 January 2018 at 14:51, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Erwan,

 

We have not looked into it yet, but there would definitely be interest from us since many of our ICs support NFC. We currently ship a binary blob in our proprietary SDK, so that is not an option.

 

Regards,

 

Carles

 

From: zephyr-users-bounces@lists.zephyrproject.org [mailto:zephyr-users-bounces@lists.zephyrproject.org] On Behalf Of Erwan Gouriou
Sent: 16 January 2018 14:44
To: Zephyr-users@lists.zephyrproject.org
Subject: [Zephyr-users] NFC Library

 

Hi all,

Does anyone have ever looked to a NFC library that could be integrated into Zephyr?

Would there be any interest?

 

Thanks

Erwan

 



Security of Mesh Network

ashish.shukla@corvi.com <ashish.shukla@...>
 

Hi Johan,

As you replied to Vikrant

"I think using public key in-band and an OOB mechanism
during the authentication stage would also help prevent MITM attacks
(though only a 128-bit randomly generated Static OOB value should be
considered as "high" security level)."

what if I use in-band mechanism to exchange public keys and during authentication stage, I changed output size of OOB number to 1 and blinked LED on the board to the same number of times. This number can be entered into provisioner to generate ConfirmationValue.

Out of these two methods
1. 128-bit randomly generated Static OOB
2.  and one I mentioned above

Which one would be more secure?  

 

--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


Re: Emulating 2(or Multiple) Network interfaces in the same QEMU Machine

Juliano S Assine
 

Thanks Michael, I was able to reproduce on my board. I was having some trouble because there is only one UART on the nrf52 DK so I couldn't access the console to see what was going on.
I agree with Paul, it took me some reading about slip and ppp, tun/tap etc, to figure things out, which is not bad, but a sample in the repo would have been really helpful.

Just a few more questions:
2 - Using the http_server example, tunslip6 -v2 works, but -v4 doesn't, there may be a bug there
3- http_server example works of firefox but not on chrome.

2018-01-13 8:55 GMT-02:00 Paul Sokolovsky <paul.sokolovsky@...>:

Hello Michael,

On Fri, 12 Jan 2018 19:58:12 +0000
Michael Hope <michaelh@...> wrote:

> It turns out that samples/net/http_server already works fine :)
>
> I had to shrink the buffer count to fit on the 32 KiB on the Arduino
> Zero though.

Sure, existing samples should work, that's the whole idea. As soon as
you enable bunch of options (and outsider would say "obscure options"),
and run stuff on a host ("obscure stuff", an outsider would say; what
do we do to run SLIP on Linux nowadays? Is it still something simple as
slirp, or it was subsumed by pppd and you need to dig into its obscure
option to make it run, jungling to not affect system-wide setup and
not get an option conflict?).

Effectively, a known working configuration and README describing the
full setup is what would comprise a SLIP sample, the code is definitely
there. So, please don't discount it as something not useful and not
worth a hacking pleasure ;-).

>
> -- Michael
>
> On Thu, 11 Jan 2018 at 00:15 Paul Sokolovsky
> <paul.sokolovsky@...> wrote:
>
> > Hello Michael,
> >
> > On Mon, 08 Jan 2018 18:35:48 +0000
> > Michael Hope <michaelh@...> wrote:
> >
> > []
> >
> > > > 2. If I have a physical device, can I emulate a networking
> > > > connection using UART in the same fashion?
> > > >
> > >
> > > Yip, this works well.  One of the first things I did when I
> > > picked up Zephyr was configure SLIP and ping the board :)
> >
> > Perhaps, you should contribute a sample application to samples/ for
> > that ;-).

[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: NFC Library

Carles Cufi
 

Hi Erwan,

 

We have not looked into it yet, but there would definitely be interest from us since many of our ICs support NFC. We currently ship a binary blob in our proprietary SDK, so that is not an option.

 

Regards,

 

Carles

 

From: zephyr-users-bounces@... [mailto:zephyr-users-bounces@...] On Behalf Of Erwan Gouriou
Sent: 16 January 2018 14:44
To: Zephyr-users@...
Subject: [Zephyr-users] NFC Library

 

Hi all,

Does anyone have ever looked to a NFC library that could be integrated into Zephyr?

Would there be any interest?

 

Thanks

Erwan

 


NFC Library

Erwan Gouriou
 

Hi all,

Does anyone have ever looked to a NFC library that could be integrated into Zephyr?
Would there be any interest?

Thanks
Erwan


Re: understanding of #BluetoothMesh OOB authentication procedure #bluetoothmesh

Vikrant More <vikrant8051@...>
 

Hi Johan,

Thanks for your reply.



I've been further clearing my concept by reading above two links along with Mesh Specs.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
When I comment-out following lines as below

static const struct bt_mesh_prov prov =
{
    .uuid = dev_uuid,
    //.output_size = 4,
    //.output_actions = BT_MESH_BLINK | BT_MESH_BEEP | BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
    //.output_number = output_number,

    .complete = prov_complete,
    .reset = prov_reset,
};

, flowchart (5.4.2) follows path as per attached FlowChart_1.pdf. Am I right ?

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

& when I uncomment following lines as below

static const struct bt_mesh_prov prov =
{
    .uuid = dev_uuid,
    .output_size = 4,
    .output_actions = BT_MESH_BLINK | BT_MESH_BEEP | BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
    .output_number = output_number,

    .complete = prov_complete,
    .reset = prov_reset,
};

, flowchart follows path as per attached FlowChart_2.pdf. Am I right ?

[  Here in both the cases, I'm assuming DEVICE generate dynamic public key (non OOB public key) which gets transfer over Bluetooth-LinK (non-OOB channel)
   And it is used by ECDH to calculate ECDHSecret on provisioner side ]
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

DEVICE's Public key can be static or dynamic plus it can exchange over Bluetooth-Link or OOB. Am I right ?

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

As per current implementation, we are using dynamic Public Key
& both sides public keys are get exchanged over Bluetooth-Link instead of OOB. Am I right ?

But when I want to use static Public-Private keys for DEVICE (provisioner may have dynamic pair), how & where to edit so that provisioner will
understand that DEVICE has static public key ?

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

How provisioner will understand from where to received/read DEVICE public key out of Bluetooth-Link or OOB channel ?
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

If public keys get exchanged over insecure channel, then what is significance of OOB tunnel over Bluetooth-Link ?

------------------------------------------------------------------------------------------------------------------------------------------------------------------------

I agree that, Bluetooth Specs has already provided details but it not easy to interpret its correct meaning


On Mon, Jan 15, 2018 at 8:42 PM, Johan Hedberg <johan.hedberg@...> wrote:
Hi Vikrant,

On Mon, Jan 15, 2018, Vikrant More wrote:
> By reading this link, I understood that netKey, appKey, dveKey are
> AES-128 *symmetric
> keys* which are exchanged over encrypted *channel* during provisioning.

That's not completely true. Only the primary netkey and the devkey are
distributed to the node during provisioning. The other netkeys (if any)
and appkeys are distributed during the configuration phase over mesh,
and are encrypted using the keys that were distributed during
provisioning phase (primary netkey and devkey).

> This encrypted *channel* is based on public-private keys. Provisioner has
> its combo of keys & similarly DEVICE has its own.
> And to create this channels both parties should aware of public-key of each
> other.
>
> And there are two ways to exchange public keys viz;
> 1) in-band
> 2) out-of-band (OOB) (eg. NFC, QR code )
>
> Two avoid *man-in-the-middle attacks *we should go with OOB
> *. *
>
>
> *Up till this, Am I right ?*

Yes, however I think using public key in-band and an OOB mechanism
during the authentication stage would also help prevent MITM attacks
(though only a 128-bit randomly generated Static OOB value should be
considered as "high" security level).

> *So my question is, in case of Zephyr's #BluetoothMesh where is DEVICE's
> private & public keys stored ? *

The ECDH crypto is implemented in subsys/bluetooth/host/hci_ecc.c, and
it's based on TinyCrypt (which in turn is based on uECC, but let's not
get into those details :)

> *And how to update that pair from default one ? *

Currently all these APIs are internal, but we could (and perhaps should)
make them public. They reside in subsys/bluetooth/host/ecc.h currently.
There's e.g. bt_pub_key_get() which gives you the current public key
value (e.g. to be sent over an OOB channel), and bt_pub_key_gen() to
generate a new public-private keypair. Currently a new key pair gets
generated every time you initialize Bluetooth (by calling bt_enable).

> But when we enable this,
>
>     .output_size = 6,  //4
>     .output_actions = BT_MESH_BLINK | BT_MESH_BEEP | BT_MESH_VIBRATE |
> BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
>     .output_number = output_number,
>     .output_string = output_string,
>
> & we get 4 digits or 6 digits or random string on DEVICE's serial terminal,
> then what is this ? this is obviously not any type of public-key ?
> Could anybody explain me, what is going on ? What is Static OOB, Output
> OOB, Input OOB ?
>
> How Static OOB, Output OOB, Input OOB are related with the public-keys
> exchange which I've mentioned above ?

Those are steps that can happen after the public key exchange. I really
recommend you to read through section "5.4.2 Provisioning behavior" in
the Mesh Profile specification. Its subsections correspond to the
various stages that provisioning goes through. E.g. section 5.4.2.3 is
the public key exchange, and section 5.4.2.4 (called "Authentication")
the one where the Static/Output/Input OOB methods can be applied.

> If Zephyr does not have own copy of public-private keys for OOB, then how
> to generate & add them in firmware ?
> How to link them with above mentioned mechanism ?

As I mentioned earlier, by making the ecc.h header file public, we could
give the app access the the public key and make it possible for it to
transfer it out-of-band to the provisioner.

One thing that is missing (since the public key APIs were not previously
available to the app) is the ability for the app to influence the
Provisioning Capabilities PDU that we send to include a flag that says
"OOB Public Key available". It's a fairly simple thing to fix though -
it'd just be one more u8_t field to the bt_mesh_prov struct.

Johan


Re: understanding of #BluetoothMesh OOB authentication procedure #bluetoothmesh

Johan Hedberg
 

Hi Vikrant,

On Mon, Jan 15, 2018, Vikrant More wrote:
By reading this link, I understood that netKey, appKey, dveKey are
AES-128 *symmetric
keys* which are exchanged over encrypted *channel* during provisioning.
That's not completely true. Only the primary netkey and the devkey are
distributed to the node during provisioning. The other netkeys (if any)
and appkeys are distributed during the configuration phase over mesh,
and are encrypted using the keys that were distributed during
provisioning phase (primary netkey and devkey).

This encrypted *channel* is based on public-private keys. Provisioner has
its combo of keys & similarly DEVICE has its own.
And to create this channels both parties should aware of public-key of each
other.

And there are two ways to exchange public keys viz;
1) in-band
2) out-of-band (OOB) (eg. NFC, QR code )

Two avoid *man-in-the-middle attacks *we should go with OOB
*. *


*Up till this, Am I right ?*
Yes, however I think using public key in-band and an OOB mechanism
during the authentication stage would also help prevent MITM attacks
(though only a 128-bit randomly generated Static OOB value should be
considered as "high" security level).

*So my question is, in case of Zephyr's #BluetoothMesh where is DEVICE's
private & public keys stored ? *
The ECDH crypto is implemented in subsys/bluetooth/host/hci_ecc.c, and
it's based on TinyCrypt (which in turn is based on uECC, but let's not
get into those details :)

*And how to update that pair from default one ? *
Currently all these APIs are internal, but we could (and perhaps should)
make them public. They reside in subsys/bluetooth/host/ecc.h currently.
There's e.g. bt_pub_key_get() which gives you the current public key
value (e.g. to be sent over an OOB channel), and bt_pub_key_gen() to
generate a new public-private keypair. Currently a new key pair gets
generated every time you initialize Bluetooth (by calling bt_enable).

But when we enable this,

.output_size = 6, //4
.output_actions = BT_MESH_BLINK | BT_MESH_BEEP | BT_MESH_VIBRATE |
BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
.output_number = output_number,
.output_string = output_string,

& we get 4 digits or 6 digits or random string on DEVICE's serial terminal,
then what is this ? this is obviously not any type of public-key ?
Could anybody explain me, what is going on ? What is Static OOB, Output
OOB, Input OOB ?

How Static OOB, Output OOB, Input OOB are related with the public-keys
exchange which I've mentioned above ?
Those are steps that can happen after the public key exchange. I really
recommend you to read through section "5.4.2 Provisioning behavior" in
the Mesh Profile specification. Its subsections correspond to the
various stages that provisioning goes through. E.g. section 5.4.2.3 is
the public key exchange, and section 5.4.2.4 (called "Authentication")
the one where the Static/Output/Input OOB methods can be applied.

If Zephyr does not have own copy of public-private keys for OOB, then how
to generate & add them in firmware ?
How to link them with above mentioned mechanism ?
As I mentioned earlier, by making the ecc.h header file public, we could
give the app access the the public key and make it possible for it to
transfer it out-of-band to the provisioner.

One thing that is missing (since the public key APIs were not previously
available to the app) is the ability for the app to influence the
Provisioning Capabilities PDU that we send to include a flag that says
"OOB Public Key available". It's a fairly simple thing to fix though -
it'd just be one more u8_t field to the bt_mesh_prov struct.

Johan


understanding of #BluetoothMesh OOB authentication procedure #bluetoothmesh

Vikrant More <vikrant8051@...>
 

Hello World !!

By reading this link, I understood that netKey, appKey, dveKey are AES-128 symmetric keys which are exchanged over encrypted channel during provisioning.

This encrypted channel is based on public-private keys. Provisioner has its combo of keys & similarly DEVICE has its own.
And to create this channels both parties should aware of public-key of each other.

And there are two ways to exchange public keys viz;
1) in-band
2) out-of-band (OOB) (eg. NFC, QR code )

Two avoid man-in-the-middle attacks we should go with OOB.

Up till this, Am I right ?

So my question is, in case of Zephyr's #BluetoothMesh where is DEVICE's private & public keys stored ?
And how to update that pair from default one ?

//----------------------------------------------------------------------------------------------------------------------------------------------------------------

Previously, I had asked following Question, (at that time I had forgotten to add zephyr-devel@... in CC)

//----------------------------------------------------------------------------------------------------------------------------------------------------------------


For testing I always comment-out following lines

    //.output_size = 6,
    //.output_actions = (BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING),
    //.output_number = output_number,
    //.output_string = output_string,

,otherwise I have to read that value from nRF52 terminal .

How this mechanism is going to work with actual products based on #BluetoothMesh ?

We can't ask consumer or end-user to attach device to serial terminal to get that value like we does to complete OOB-authentication procedure.

On that Mr. Johan replied as ->

In the Mesh Profile Specification, you can find the other types of input
& output OOB actions e.g. under section 5.4.1.2, in particular tables
5.22 and 5.24. The only reason the sample apps use display number/string
is that they're designed for a setup with a text-based console.

That said, the general consensus within the Mesh WG is that the
input/output OOB action mechanism is not sufficiently secure and should
only be considered to be a minor improvement over non-interactive
provisioning. The recommendation for secure provisioning is to use OOB
Public Key transfer or a 16-byte static OOB value. The actual mechanism
to do this is left up to the implementation - you can e.g. have a URL in
the node's advertising data or have a QR code printed on the node which
the provisioner reads. Using NFC is another option. IIRC, there should
be a whitepaper coming out from the Mesh WG soon which covers
recommended practices for secure provisioning.
//-------------------------------------------------------------------------------------------------------------------------------------------------------------
//-------------------------------------------------------------------------------------------------------------------------------------------------------------

But when we enable this,

    .output_size = 6,  //4
    .output_actions = BT_MESH_BLINK | BT_MESH_BEEP | BT_MESH_VIBRATE | BT_MESH_DISPLAY_NUMBER | BT_MESH_DISPLAY_STRING,
    .output_number = output_number,
    .output_string = output_string,

& we get 4 digits or 6 digits or random string on DEVICE's serial terminal, then what is this ? this is obviously not any type of public-key ?
Could anybody explain me, what is going on ? What is Static OOB, Output OOB, Input OOB ?

How Static OOB, Output OOB, Input OOB are related with the public-keys exchange which I've mentioned above ?

If Zephyr does not have own copy of public-private keys for OOB, then how to generate & add them in firmware ?
How to link them with above mentioned mechanism ?


Thank You !!





Re: Emulating 2(or Multiple) Network interfaces in the same QEMU Machine

Paul Sokolovsky
 

Hello Michael,

On Fri, 12 Jan 2018 19:58:12 +0000
Michael Hope <michaelh@juju.nz> wrote:

It turns out that samples/net/http_server already works fine :)

I had to shrink the buffer count to fit on the 32 KiB on the Arduino
Zero though.
Sure, existing samples should work, that's the whole idea. As soon as
you enable bunch of options (and outsider would say "obscure options"),
and run stuff on a host ("obscure stuff", an outsider would say; what
do we do to run SLIP on Linux nowadays? Is it still something simple as
slirp, or it was subsumed by pppd and you need to dig into its obscure
option to make it run, jungling to not affect system-wide setup and
not get an option conflict?).

Effectively, a known working configuration and README describing the
full setup is what would comprise a SLIP sample, the code is definitely
there. So, please don't discount it as something not useful and not
worth a hacking pleasure ;-).


-- Michael

On Thu, 11 Jan 2018 at 00:15 Paul Sokolovsky
<paul.sokolovsky@linaro.org> wrote:

Hello Michael,

On Mon, 08 Jan 2018 18:35:48 +0000
Michael Hope <michaelh@juju.nz> wrote:

[]

2. If I have a physical device, can I emulate a networking
connection using UART in the same fashion?
Yip, this works well. One of the first things I did when I
picked up Zephyr was configure SLIP and ping the board :)
Perhaps, you should contribute a sample application to samples/ for
that ;-).
[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Emulating 2(or Multiple) Network interfaces in the same QEMU Machine

Michael Hope
 

It turns out that samples/net/http_server already works fine :)

I had to shrink the buffer count to fit on the 32 KiB on the Arduino Zero though.

-- Michael

On Thu, 11 Jan 2018 at 00:15 Paul Sokolovsky <paul.sokolovsky@...> wrote:
Hello Michael,

On Mon, 08 Jan 2018 18:35:48 +0000
Michael Hope <michaelh@...> wrote:

[]

> > 2. If I have a physical device, can I emulate a networking
> > connection using UART in the same fashion?
> >
>
> Yip, this works well.  One of the first things I did when I picked up
> Zephyr was configure SLIP and ping the board :)

Perhaps, you should contribute a sample application to samples/ for
that ;-).

>
> -- Michael



--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Re: Emulating 2(or Multiple) Network interfaces in the same QEMU Machine

Michael Hope
 

One possibility: the host address should be 2001:db8::2, not ::1.

The net shell is also very useful.  Try 'select net' and 'stats'.  I see things like this:

Host side:

********SLIP started on ``/dev/ttyUSB0''
slipfd and inslip reopened
ip neigh flush dev tap0
Cannot find device "tap0"
opened tap device ``/dev/tap0''
ifconfig tap0 up
ip -6 route add 2001:db8::/64 dev tap0
ip -6 addr add 2001:db8::2/64 dev tap0
ip route add 192.0.2.0/24 dev tap0
ip addr add 192.0.2.2/24 dev tap0
ifconfig tap0

tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.0.2.2  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 2001:db8::2  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::144a:22ff:feff:a9bf  prefixlen 64  scopeid 0x20<link>
        ether 16:4a:22:ff:a9:bf  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap0: Packet from TUN of length 90 - write SLIP
tap0: Packet from TUN of length 110 - write SLIP
tap0: Packet from TUN of length 74 - write SLIP
tap0: Packet from TUN of length 54 - write SLIP
tap0: Packet from TUN of length 86 - write SLIP

Device side:

shell> select net
net> stats
IPv6 recv      13       sent    8       drop    0       forwarded       0
IPv6 ND recv   2        sent    5       drop    2
IPv6 MLD recv  0        sent    3       drop    0
IP vhlerr      0        hblener 0       lblener 0
IP fragerr     0        chkerr  0       protoer 0
ICMP recv      10       sent    3       drop    8
ICMP typeer    0        chkerr  0
UDP recv       0        sent    0       drop    3
UDP chkerr     0
TCP bytes recv 0        sent    0
TCP seg recv   0        sent    0       drop    0
TCP seg resent 0        chkerr  0       ackerr  0
TCP seg rsterr 0        rst     0       re-xmit 0
TCP conn drop  0        connrst 0
Bytes received 1584
Bytes sent     564
Processing err 5

-- Michael

On Wed, 10 Jan 2018 at 19:27 Juliano Siloto Assine <jsiloto@...> wrote:
2018-01-08 16:35 GMT-02:00 Michael Hope <michaelh@...>:
Hi Juilano.  Replies inline...

On Mon, 8 Jan 2018 at 13:37 Juliano Siloto Assine <jsiloto@...> wrote:
Hello,
Sorry for anything confusing, first timer here, I have a couple of questions.

1. Lets say I'm running one of the networking examples using DBOARD=quemu_cortex_m3.
When I build it with make client/server it runs qemu with the "-serial pipe:/tmp/ip-stack-${target}" flag and link client and server via simlink.

qemu(server) -----> /tmp/ip-stack-server.out ---> /tmp/ip-stack-client.in -----> qemu(client)

As qemu support up to 4 virtual serial ports via the -serial flag, can I have multiple network interfaces on the same emulated machine?

Currently, no.  You can only run one instance of the SLIP interface partly as it depends on the single-instance uart_pipe code.


quemu(client2) <-- ip-stack-client2.in <-- ip-stack-server2.out <-- qemu(client)qemu(server) --> ip-stack-server1.out --> ip-stack-client1.in --> qemu(client1)

2. If I have a physical device, can I emulate a networking connection using UART in the same fashion?

Yip, this works well.  One of the first things I did when I picked up Zephyr was configure SLIP and ping the board :)

Any suggestions as to how?
If I use uart0 as uart-pipe I can ping a qemu instance but not my physical board.

On qemu I am running with the flag -serial unix:/tmp/slip.sock and using net/tools scripts -serial unix:/tmp/slip.sock
On my board (nrf52_pca10040) I am trying to use tunslip6 directly like:
> sudo ./tunslip6 -B 115200 -s /dev/ttyUSB0 -T -v2 2001:db8::1/64 &
 

-- Michael

_______________________________________________
Zephyr-users mailing list
Zephyr-users@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-users

2321 - 2340 of 2796