Arduino IoT security libraries?

630 views
Skip to first unread message

Alex Albino

unread,
Feb 12, 2019, 6:01:17 PM2/12/19
to devel...@arduino.cc
Are there any Arduino libraries that address IoT security issues?

I'm specifically looking for libraries that may get packaged with Arduino Zero (Cortex M0+ or higher) IoT boards.

SSL libraries? Password management? Hardened RF communications? etc. 

If I'm asking the wrong questions, my apologies. 

Thank you in advance.

PS - If anyone is interested in talking about secure IoT development, there's an event in LA through MyHackerHouse (June) that is welcoming IoT devs to discuss IoT firmware and security. I figure Arduino IoT devs would be very welcome. 

Tom Igoe

unread,
Feb 12, 2019, 9:27:02 PM2/12/19
to devel...@arduino.cc
SSL's already built into the WiFi101 and WiFiNINA libraries. See:


And the instructions on adding SSL certs to the MKR1000: 

that same process works for the WiFiNINA in version 1.8.8 of the IDE.  Cristian and Arturo can probably say more about it, but I can verify that they work, I tested them for class this morning. 



--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

Jacob Christ

unread,
Feb 13, 2019, 2:30:52 AM2/13/19
to Arduino Developers
SSL is a beast. The smallest footprint version I am aware of is Dropbear and it would probably be quite difficult to shoehorn into an AT chip. Might be able to get it working on a 32bit core. I dream of free time when I might give it a wack on a pic32 running RetroBSD.

Jacob

--

Massimo Banzi

unread,
Feb 13, 2019, 4:17:00 AM2/13/19
to Arduino Developers
Thanks to the efforts of Sandeep Mistry we have BearSSL running on the cortexM0+ 



This is the smallest SSL we found.


 
--

Massimo Banzi
Co-Founder


Don Coleman

unread,
Feb 13, 2019, 1:11:21 PM2/13/19
to devel...@arduino.cc
The MKR boards have an ECC508/ECC608 crypto chip. This chip lets you generate a private key on the device that can never leave the device. You use the private key to generate a CSR for certificate based authentication. This works great for AWS IoT Core. Sandeep has an excellent guide for getting started https://create.arduino.cc/projecthub/Arduino_Genuino/securely-connecting-an-arduino-mkr-wifi-1010-to-aws-iot-core-a9f365.

Aaron Williams

unread,
Feb 13, 2019, 4:31:50 PM2/13/19
to devel...@arduino.cc
There is always mbedtls which is quite a bit smaller. The ESP32 includes it in ROM.

-Aaron

Massimo Banzi

unread,
Feb 14, 2019, 1:43:30 AM2/14/19
to Arduino Developers
Actually mbedtls is larger than bearssl that's why we use it 

M

John Davis

unread,
Aug 11, 2021, 12:17:05 PM8/11/21
to Developers, Massimo Banzi
I am unable to use the Arduino cloud provider example - for google cloud platform using MKR1000.

In an effort to understand where the failure is occurring I'm trying to debug the problem.

I am still learning ssl and arduino, so I apologize if the questions are dumb but using the forums, filing issues and stack overflow posts are not getting much traction.

From what I have seen there are two code examples out there.  1) the arduino cloud provider examples the mkr1000 uses the crypto chip 2) the GCP MKR1000 sample from google which does not use the crypto chip but instead hard codes the key in the firmware.

Both use the root cert uploaded to the arduino using the firmware/certificate utility.

Where is this root/cert in the firmware used?  If I have uploaded it to the device, is there a way to query it from sketch land?  Is it only avaialble in the arduino firmware and hidden for regular users?

Charles Papir

unread,
Aug 11, 2021, 1:59:54 PM8/11/21
to devel...@arduino.cc, John Davis, Massimo Banzi
I have been doing development on Arduino platforms (UNO, UNO WiFi Arduino Nano 33, MKR ZERO, Mega 2560, ESP-32, Arduino ZERO) for IoT projects for several years. It is difficult. We have several products out.

If you can be a bit clearer on what you are trying to accomplish I may be able to help.

Charlie Papir

John Davis

unread,
Aug 11, 2021, 2:51:29 PM8/11/21
to Charles Papir, devel...@arduino.cc
Hello Charles

This is kindest words I’ve heard in a long time.

“ If you can be a bit clearer on what you are trying to accomplish I may be able to”

Many thanks.  

I’m using a mkr1000 and my pal is using a mat gsm 1300?  I don’t know much about his card but he had the same problem as I.  Ie with a cert loaded to gcp iOt core he could not connect.  I have the same issue.

I’ve used the arduino sample and arduino tutorial write up and it does not work.

I’ve used the google sample and their readme and it also fails.

I have a write up on the google sample how I approached their guide and I have a wireshark capture write up as well.

At this point I’m no longer trying to do MQTT to google.  I’ll be happy if I can simply connect via https to a webserver.

Rather than show you a bunch of capture file and discussion for the gcp mqtt attempt with google sample perhaps I should ask which tutorial do you know that actually works?  

If so I’ll try that particular example/tutorial and report back to you.

For what it’s worth the https sample is looking for a shield.  Is there one for mkr1000?

Thanks again 

John
--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358
Public Profile https://www.linkedin.com/in/netskink

独树一帜

John Davis

unread,
Aug 11, 2021, 7:40:08 PM8/11/21
to devel...@arduino.cc

Fwiw here are the results of the https and icmp for the arduino.  I’m still working on the mqtt problem.
On Wed, Aug 11, 2021 at 13:59 Charles Papir <ml0...@gmail.com> wrote:

Tom Igoe

unread,
Aug 11, 2021, 9:04:45 PM8/11/21
to devel...@arduino.cc
Happy to share https and mqtt examples using the Arduino libraries if it's useful, I use them a lot. All variations on the same theme:




These were all written for novice programmers, so apologies if they're to basic for what you need.

Tom


Tom Igoe

unread,
Aug 11, 2021, 9:13:24 PM8/11/21
to devel...@arduino.cc
Oh, one thing that may be useful: Google scripts does a  thing where it gives you a http 302 redirect response that's kind of nonstandard, as an https measure. Stumped me for a bit. Might be true for the Google cloud api too.


On Wed, Aug 11, 2021, 7:40 PM John Davis <dav...@gmail.com> wrote:

John Davis

unread,
Aug 11, 2021, 10:21:12 PM8/11/21
to devel...@arduino.cc
On Wed, Aug 11, 2021 at 21:04 Tom Igoe <t.i...@arduino.cc> wrote:
Happy to share https and mqtt examples using the Arduino libraries if it's useful, I use them a lot. All variations on the same theme:



Those looks like some I haven’t seen yet.  I just updated the steps I took.  I wonder if I am doing the firmware cert update and the private key generation correctly.  I have the code and method here 


Thanks for these below.  I’ll look at them tomorrow.  Im kinda beat now.

Tom Igoe

unread,
Aug 12, 2021, 8:26:28 AM8/12/21
to devel...@arduino.cc
I never bother to generic a cert or key with Google, I just use the ones that ship on the board.  The default one handles requests to them just fine in my experience.

John Davis

unread,
Aug 12, 2021, 9:40:48 AM8/12/21
to devel...@arduino.cc
Hmm that is good to know.  Does it matter what cert is loaded with the firmware/certificate utility before the microchip crypto chip generates a key?

I read something about the cert and key need to be paired to preserve the chain of trust.  Also the example used to generate the key/web token says it’s a self signed cert.  I wonder if that could be the problem.  I don’t know enough about ssl at this point to know.

Tom Igoe

unread,
Aug 12, 2021, 10:12:20 AM8/12/21
to devel...@arduino.cc
Someone on the current dev team should comment here rather than me becuase I'm not as current on the maintenance of the WIFi101 and WiFiNINA libs, but what I can tell you is this:

For http and https, I use the ArduinoHttpClient lib, which is a fork of Adrian McEwen's excellent http client lib. It uses the WiFi101 or wifiNINA libs under the hood. They both have a class called wifiSSLclient which handles all the SSL work for me, including interaction with the crypto chip. The certificates in the crypto chip when it ships have always worked for sites I needed. So I've never really bothered to upload certs through the firmware updater and cert loader tool other than to learn how to use it. This section of that guide may help you. To be honest, I forget what cert is loaded on when the boards ship, but hopefully someone on the dev team who currently maintains the Wifi boards can say. 

Tom

John Davis

unread,
Aug 12, 2021, 10:31:29 AM8/12/21
to devel...@arduino.cc
Hello Tom,

Comments inline

On Thu, Aug 12, 2021 at 10:12 AM Tom Igoe <t.i...@arduino.cc> wrote:
Someone on the current dev team should comment here rather than me becuase I'm not as current on the maintenance of the WIFi101 and WiFiNINA libs, but what I can tell you is this:


No worries.  i'm happy to simply discuss the problem. 
 
For http and https, I use the ArduinoHttpClient lib, which is a fork of Adrian McEwen's excellent http client lib. It uses the WiFi101 or wifiNINA libs under the hood. They both have a class called wifiSSLclient which handles all the SSL work for me, including interaction with the crypto

Yes, I've looked through the WiFiSSLClient and WiFiClient code.  I don't know 100% how it works, but a little.  I don't think any of the "user" code, ie. code in ~/Arduino/libraries has any iteraction with the crypto chip and cert manipulation.  I believe that is in the Client firmware.  Perhaps I am wrong.  I'm writing based upon memory and even then its complicated.  I'm basing this on the fact that I saw socket options for SSL being set in the "user" code but nothing more.

I did use put the Https Client code I used in the github and the results of it connecting to google with and without the google.com:443 entry in the utility.  I have the capture files for both situations.  I have not looked at them in depth yet.  If you are interested the capture files are in that repo as well.  I'll eventually look at them in detail myself.

 
chip. The certificates in the crypto chip when it ships have always worked for sites I needed. So I've never really bothered to upload certs through the firmware updater and cert loader tool other than to learn how to use it. This section of that guide may help you. To be honest, I forget what cert is loaded on when the boards ship, but hopefully someone on the dev team who currently maintains the Wifi boards can say. 

Tom


Yes, that guide tells how to operate the tool.  Not so much how the results are used.  The guide did do a good job of its stated purpose though.  I had no problem using it as a guide on how to use the tool.  In regards to how they ship, they have a single domain arduino.cc:443 loaded.  At least that is the default when the tool when the is run.

 

Tom Igoe

unread,
Aug 12, 2021, 10:49:22 AM8/12/21
to devel...@arduino.cc


On Thu, Aug 12, 2021, 10:31 AM John Davis <dav...@gmail.com> wrote:

Yes, I've looked through the WiFiSSLClient and WiFiClient code.  I don't know 100% how it works, but a little.  I don't think any of the "user" code, ie. code in ~/Arduino/libraries has any iteraction with the crypto chip and cert manipulation.  I believe that is in the Client firmware.  Perhaps I am wrong. 

Hmm... I thought the WiFiBearSSL lib, which is used by the  lib, accessed the ECCx08 lib, but I have to defer to the devs on that. 

I'm writing based upon memory and even then its complicated.  I'm basing this on the fact that I saw socket options for SSL being set in the "user" code but nothing more.

The main diff for me  is generally using the  WiFiSSLClient instead of WiFiClient and changing the port. That's why I assumed the above about the crypto lib. 

I did use put the Https Client code I used in the github and the results of it connecting to google with and without the google.com:443 entry in the utility.

This might be the problem. For the server path, you don't want to include the port. That is set separately, see my examples for that. That's a common mistake I see students make. Similarly, don't include the http or https in your server path. The client lib adds those too, depending on whether you're using the SSL or ain client.

Does that help at all? I feel like I'm off base here. 


Tom


John Davis

unread,
Aug 12, 2021, 11:04:44 AM8/12/21
to devel...@arduino.cc


Comments inline

On Thu, Aug 12, 2021 at 10:49 AM Tom Igoe <t.i...@arduino.cc> wrote:


On Thu, Aug 12, 2021, 10:31 AM John Davis <dav...@gmail.com> wrote:

Yes, I've looked through the WiFiSSLClient and WiFiClient code.  I don't know 100% how it works, but a little.  I don't think any of the "user" code, ie. code in ~/Arduino/libraries has any iteraction with the crypto chip and cert manipulation.  I believe that is in the Client firmware.  Perhaps I am wrong. 

Hmm... I thought the WiFiBearSSL lib, which is used by the  lib, accessed the ECCx08 lib, but I have to defer to the devs on that. 


It very well could be.  I have not looked at the source which makes the binary on the arduino which our library/sketch code uses/works with.  I do know that I don't have a WiFiBearSSL library in my ~/Arduino/libraries folder.


 
I'm writing based upon memory and even then its complicated.  I'm basing this on the fact that I saw socket options for SSL being set in the "user" code but nothing more.

The main diff for me  is generally using the  WiFiSSLClient instead of WiFiClient and changing the port. That's why I assumed the above about the crypto lib. 

To be honest, when I looked at the code for these two classes in the WiFi101 lib dir, I was puzzled why one is just a wrapper around the other.  For referrence here is the definition:

class WiFiSSLClient : public WiFiClient {

public:
        WiFiSSLClient();
        WiFiSSLClient(uint8_t sock);

        virtual int connect(IPAddress ip, uint16_t port);
        virtual int connect(const char* host, uint16_t port);
};

The connect calls are wrappers around the WiFiClient::connect.  Basically specify a hostname&port or ip addr&port and its wrapped
to the hostname, ip addr and port variant.  Later it adds socket options.  Like I said, I was wondering why make a simple wrapper.  Later I thought maybe they were doing it for maintainability or future upgrades/modifications.   I read later that it might be to create a similar api method.

 

I did use put the Https Client code I used in the github and the results of it connecting to google with and without the google.com:443 entry in the utility.

This might be the problem. For the server path, you don't want to include the port. That is set separately, see my examples for that. That's a common mistake I see students make. Similarly, don't include the http or https in your server path. The client lib adds those too, depending on whether you're using the SSL or ain client.


Hmm.  The tool requires a port.  Hence I show I have the following settings in that tool:


Later the code in the example sample specifies the port.

From the Https client sketch : client.connect(server, 443)
From the GCP-Mqtt client sketch: mqttClient.connect(broker, 8883))

Both of these samples as I used them are in that repo I made for this problem.

 
Does that help at all? I feel like I'm off base here. 


Yes, it helps.  I appreciate it.  Like I said, I'm happy to talk about it and I enjoy your assistance.

 

Tom Igoe

unread,
Aug 12, 2021, 11:11:25 AM8/12/21
to devel...@arduino.cc
I think I need to take a deeper look at your repo, and not on my phone, to give a decent answer. Will try to do so later on, when I'm alone. I'm taking shots in the dark here, sorry. I have a hunch it's something in the user facing code tho, and not deeper in the lib....

Tom

John Davis

unread,
Aug 12, 2021, 8:40:50 PM8/12/21
to devel...@arduino.cc
Hmm.  I compared the traffic between the HTTPS client which works and the SSL/MQTT which fails.

Both scenarios start the same

1. Client Hello
2. Server Hello
3. Certificate, Server Hello Done

I examined the Certificate frame in either case and they were the same two certificates.  

4.  Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 

The client sends the same headers for each message: TLS1.2.  I did not compare the Encrypted Handshake Message.

5. Change Cipher Spec, Encrypted Handshake Message

The server sends this message.  I don't see anything in particular in these two fields.  I'm guessing its an ack that
it read the message.

And then is where it differs, the client in both cases sends Encrypted Applicaiton Data.  However, in the case of the 
HTTPS client(ardujono), it sends around 10 of these frames to the server.  Then in the case of the HTTPS, the
server sends more than 30 frames in response.  In the MQTT situation after the client sends one frame of the Encruypted
application data, the server sends a ACK frame and then a ACK Fin=1 frame.


This is covered here in more detail https://github.com/netskink/ssl_publy 

Juraj Andrássy

unread,
Aug 13, 2021, 1:40:08 AM8/13/21
to Developers, dav...@gmail.com
The crypto chip is only used for authentication on Arduino Cloud.
WiFiSSLClient of WiFiNina and WiFi101 uses secure TCP connection capabilities of the WiFi module and it can be used with any Arduino.


Dátum: piatok 13. augusta 2021, čas: 2:40:50 UTC+2, odosielateľ: dav...@gmail.com

Dario Pennisi

unread,
Aug 13, 2021, 9:23:38 AM8/13/21
to Developers, dav...@gmail.com
Hi,
not had time to look at your repo but jumping in to provide some clarifications:
- ArduinoBearSSL library implements SSL and has a list of trusted anchors that may not contain the root CA your certificate has been issued with. the reason for this is that embedded devices have small memory and we tried to keep the size small. you can of course add your own trusted CA in there at any time. you can look at this commit for an example on how to do it (Add DigitCertGlobalRootCA as trust anchor · arduino-libraries/ArduinoBearSSL@026f174 (github.com))
- cryptochip is used only for client authentication to a server. the way it works is that for example when connecting to Arduino IoT Cloud the client authenticates the server checking if its certificate was issued by a trusted root CA AND the server authenticates the client using the certificate that's stored in the crypto. this last part is important because the certificate never exits the crypto and bearSSL has been modified to send challenges to crypto and receive ecnrypted responses from it. if you had the certificate in your code some one could extract it in a much easier way than it could from the crypto
- in most recent versions of our libraries we switched to SSL offloading on modems. this is happening both on MKRWiFi1010 (where SSL stack is running on Nina wifi module) and MKR GSM (where we use the SSL AT commands from the modem). this means that for these versions we can get rid of bearSSL greatly reducing the usage of flash and, most importantly RAM which i a very scarce resource in SAMD21

Dario

Tom



Comments inline


Tom


To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
--

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
--

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358
Public Profile https://www.linkedin.com/in/netskink

独树一帜

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.


--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358
Public Profile https://www.linkedin.com/in/netskink

独树一帜

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.


--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358
Public Profile https://www.linkedin.com/in/netskink

独树一帜

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

John Davis

unread,
Aug 13, 2021, 10:09:42 AM8/13/21
to Dario Pennisi, Developers
Hello Dario,

Cool.  Comments inline

On Fri, Aug 13, 2021 at 9:00 AM Dario Pennisi <d.pe...@arduino.cc> wrote:
Hi,
not had time to look at your repo but jumping in to provide some clarifications:

No worries.  There is a lot there, but towards the end of the readme is where I compare the HTTPS and MQTT/SSL traffic.  Look there first if you do.  I appreciate your expertise and clarifications.
 
- ArduinoBearSSL library implements SSL and has a list of trusted anchors that may not contain the root CA your certificate has been issued with. the reason for this is that embedded devices have small memory and we tried to keep the size small. you can of course add your own trusted CA in there at any time. you can look at this commit for an example on how to do it (Add DigitCertGlobalRootCA as trust anchor · arduino-libraries/ArduinoBearSSL@026f174 (github.com))

That link is for bearssl.  I see that its hardcoding the certs in an array.  I dont have a bearSSL library installed in arduino.  
The examples and samples do not mention it as a requirment.  

I have not looked at the code used to build the boot firmware.  Are you implying bearssl is used by this firmware?  

 
- cryptochip is used only for client authentication to a server. the way it works is that for example when connecting to Arduino IoT Cloud the client authenticates the server checking if its certificate was issued by a trusted root CA AND the server authenticates the client using the certificate that's stored in the crypto. this last part is important because the certificate never exits the crypto and bearSSL has been modified to send challenges to crypto and receive ecnrypted responses from it. if you had the certificate in your code some one could extract it in a much easier way than it could from the crypto

Yes, I think you are saying what I'm struggling to understand through experimentation.  There is the firmware maintained
certificate which is loaded by the "firmware/certificate update utility".  I show some screenshots and trafffic where if I set the certificates to be blank the HTTPS connection fails.  If I set it to google.com:443 HTTPS works.  How this works internally I do not know.  I have yet to look at the arduino source.  That is next on my todo list.

The public/private key used to identify the arduino is in the microchip crypto chip is used by the MQTT example code but not the HTTPS sample code.

In my repo I have a sketch Https/Https.ino it connects to https://www.google.com.  It requires the firmware update tool 
to have specifed google.com:443 as the domain in the add certs section.  If its missing the Https client code fails.  If its present it works.  So, don't know how it behaves at this point in the preloaded arduino firmware.  I can say this though
the Https client sample does not use the crypto chip.  You can see this example as I use it in the repo I am maintaining on this problem.

So, these are not in the Https.ino file


* #include <ArudinoECCX08.h>   missing.  This is a microchip crypto chip IC header
* #include <utility/ECCX08JSW.h>  missing.  JWS functionality.  JWT?  When I setup the crypto chip, I used the JWS example.
* ECCX08 class usage   missing.  The crypto chip class defined by the above headers.

However, all of the above are in the failing GCP-Mqtt.ino file.  Which is my version of this example


So, what is happening in the libraries for these files?

They both use WiFiSSLClient.  Where does it come from?  It comes from the library code in ~/Arduino/libraries/WiFi101

Lets look to see if any of these use the microchip crypto code and BearSSL code.  I will not limit myself to searching in the WiFi101 src.  I'll look a bit higher in the entire library folder.

davis@twenty:~/Arduino/libraries
$ find . -name "*.cpp" | xargs grep -l ECCX08
./ArduinoECCX08/src/ECCX08.cpp
./ArduinoECCX08/src/utility/PEMUtils.cpp
./ArduinoECCX08/src/utility/ECCX08CSR.cpp
./ArduinoECCX08/src/utility/ECCX08SelfSignedCert.cpp
./ArduinoECCX08/src/utility/ECCX08JWS.cpp
./ArduinoECCX08/src/utility/ASN1Utils.cpp
davis@twenty:~/Arduino/libraries

How about BearSSL? 

davis@twenty:~/Arduino/libraries
$ find . -name "*.cpp" | xargs grep -li bear
./Adafruit_GPS_Library/src/NMEA_parse.cpp
./Adafruit_GPS_Library/src/NMEA_build.cpp
davis@twenty:~/Arduino/libraries

Now perhaps as I have said before the BearSSL code might be used by the Arduino firmware.  I don't know.  I haven't looked at the arduino firmware yet.  I do know that its not in my libraries folder.  Ditto for any usage of the crypto chip in the library.


So what does WiFiClient do?  Its the base class of the WiFiSSLClient class provided by WiFi101 library.

int WiFiSSLClient::connect(IPAddress ip, uint16_t port)
{
        return WiFiClient::connectSSL(ip, port);
}

This is a wrapper.  Connect calls the base class.  What does it do?  

Well, it does some function parameter games to find the connect call which has four parameters: IP, Port, Socket Options, and hostname.  This code is about 30 lines of code.  It uses the WiFiSocket and the specified SSL socket options parameter to open a SSL connection.  It does this via the ~/Arduino/libraries/WiFi101/...utiity/WiFiSocket.cpp and h code.
I get lost at this point.  The WiFi101 library has 26 .cpp and .h files.  At this point, the only thing I see is socket code for handling open, accept, etc.  

However, if I poke around I see that ~/Arduino/libraries/WiFi101/...driver/source/m2m_ssl.c has some routines which might come into play:

* sint8 m2m_ssl_set_active_ciphersuites(uint32 u32SslCsBMP)
* NMI_API sint8 m2m_ssl_send_certs_to_winc(uint8* pu8Buffer, uint32 u32BufferSz)

etc.  Now these look like its code which might come into play during the SERVER and CLIENT HELLo frames I see in wireshark.  I'll add some print traces to see if I can see if any are hit.  Perhaps I don't need to look in Arudion firmware source.












  


 
- in most recent versions of our libraries we switched to SSL offloading on modems. this is happening both on MKRWiFi1010 (where SSL stack is running on Nina wifi module) and MKR GSM (where we use the SSL AT commands from the modem). this means that for these versions we can get rid of bearSSL greatly reducing the usage of flash and, most importantly RAM which i a very scarce resource in SAMD21


Hmm both our WiFi MKR1000 and MKRGSM cards fail to connect, so this is good to know. I thought they might share the same code.  Hopefully fixing in one place will fix both.  I don't think the GSM card uses WiFi101.h so the common problem might be in the arduino firmware.

FWIW, the MQTT libs don't use SSL

davis@twenty:~/Arduino/libraries/MQTT/src
$ find . -type f | grep -i ssl
davis@twenty:~/Arduino/libraries/MQTT/src

Its a puzzle my man.   
 
Dario

Tom



Comments inline


Tom


To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
--

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
--

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358
Public Profile https://www.linkedin.com/in/netskink

独树一帜

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.


--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358
Public Profile https://www.linkedin.com/in/netskink

独树一帜

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.


--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358
Public Profile https://www.linkedin.com/in/netskink

独树一帜

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.


--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358
Public Profile https://www.linkedin.com/in/netskink

独树一帜

Dario Pennisi

unread,
Aug 13, 2021, 10:20:34 AM8/13/21
to Developers, Dario Pennisi, dav...@gmail.com
Hi,
went a bit over the stuff you wrote and i think it's useful to add a few more things:

- certificates are a way to ensure that the device you're talking to is really the one you intend to. certificates are emitted by certification authorities and the latter have their own certificate that may be in turn issued by another certificate authority until you get to one that is called root CA which has to be trusted. when a certificate is presented it also contains the certification chain, which is basically the list of certificates of each CA until you get to the root. for this reason it is generally not correct to add non root CAs as trusted anchors because their number would be huge while root CAs are much less although more than could fit a constrained embedded application. if you want to learn a bit about this you can experiment yourself with this commandline:

openssl s_client -showcerts -servername api2.arduino.cc -connect api2.arduino.cc:443
 
where of course you can change the URLs and you'll get a list of certificates up to the root CA

- with PCs usually you're connecting to web sites and your concern is limited to authenticate the server as you don't want someone to impersonate web sites you trust, for example your bank's, as that could allow someone to steal your account data and use it on the real site... imagine for example that someone registers gmall.com... you log in there thinking it's gmail and all of a sudden your credentials are gone. on web sites it is usually bad if the server identifies you and there's a lot of effort (for clients) to anonimize as much as possible visitors. on the other hand in embedded you want to make sure devices connecting to your server are the ones you deployed in the field and not just a random malicious device that could inject bogus data in your database. for this reason in addition to server authentication iot cloud providers generally requires clients to authenticate. this means that after server certificate is validated, server will request client certificate and validate it as well. no traffic is allowed before this is successfully achieved. you can read something about this here (The Ultimate Guide to SSL/TLS Client Authentication: Know How it Works (aboutssl.org)).
the reason why we store certificate in a cryptochip is that these devices are designed to make it very hard to extract any data out of them. this is vital because often microcontrollers have vulnerabilities that allow dumping the memory or eventually you could intercept the firmware, reverse engineer it and extract the certificate. as i mentioned in a previous message, crypto never outputs the certificate but rather uses it sort of directly handles TLS traffic so that the information exchanged between microprocessor and crypto won't ever allow reconstructing client certificate, effectively making it impossible for attackers to copy it to a bogus device.

- WiFiSSLClient in wifi101 library uses the SSL stack in the radio module (the WINC1500 which is integrated in ATSAMW25 module of MKR1000) to handle HTTPS connections. this does server authentication but does NOT perform client authentication. since the SSL stack is inside the radio module you have to load certificates in it the radio module with the certificates uploader utility. once again you should be using root CA certificates instead of server certificate.

now the bad news...

mkr 1000 does NOT have a crypto chip, so the the examples in the arduino/ArduinoCloudProviderExamples: Examples of how to connect various Arduino boards to cloud providers. (github.com) won't work as the client authentication part, requiring the crypto, will simply fail, as you already noticed. 

Dario

Dario Pennisi

unread,
Aug 13, 2021, 10:25:38 AM8/13/21
to Developers, dav...@gmail.com, Developers, Dario Pennisi
it's not that big of a puzzle... there are just a few things that i think you were missing that i tried to explain in the other rather long message i sent while you were answering. bottom line is that MKR1000 CAN open HTTPS services but since it doesn't have a crypto chip we don't support (as it's not secure enough for our standards) client authentication so you won't be able to access GCP or similar.
MKR GSM can do that and in fact you have a specific example to do it but you have to carefully follow the instructions here:  Securely Connecting a MKR GSM 1400 to Google Cloud IoT Core - Arduino Project Hub

the key part is loading che client certificate in the crypto and the server certificate in the modem (if you're using the lib with offloading) or in bearSSL if you're using the version which doesn't use offloading.

 
Dario

Tom



Comments inline


Tom


To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
--

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
--

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358
Public Profile https://www.linkedin.com/in/netskink

独树一帜

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.


--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358
Public Profile https://www.linkedin.com/in/netskink

独树一帜

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.


--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358
Public Profile https://www.linkedin.com/in/netskink

独树一帜

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.


--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358
Public Profile https://www.linkedin.com/in/netskink

独树一帜

John Davis

unread,
Aug 13, 2021, 10:30:56 AM8/13/21
to Dario Pennisi, Developers
Hmm.  That is a lot of stuff.  I haven't read it all yet, but the last part stood out to me.

"mkr 1000 does NOT have a crypto chip, so the the examples in the arduino/ArduinoCloudProviderExamples: Examples of how to connect various Arduino boards to cloud providers. (github.com) won't work as the client authentication part, requiring the crypto, will simply fail, as you already noticed. "

I was playing with the crypto chip via the ECCX08 class.
I was able to do a ECCX08.random() and get a random number generated.  Looking at the code, it is sending a command to the crypto chip to get a random number.  I also was able to run the utility to generate the public key to
upload to GCP.  It would appear that it is there.  Are you sure about that?


I appreciate the additional info.  I'll try to digest what you have shown me and update my notes.  Many thanks.  

Tom



Comments inline


Tom


To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
--

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
--

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.
--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358
Public Profile https://www.linkedin.com/in/netskink

独树一帜

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.


--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358
Public Profile https://www.linkedin.com/in/netskink

独树一帜

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.


--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358
Public Profile https://www.linkedin.com/in/netskink

独树一帜

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.


--
John F. Davis
6 Kandes Court
Durham, NC 27713
919-888-8358
Public Profile https://www.linkedin.com/in/netskink

独树一帜

John Davis

unread,
Aug 13, 2021, 10:59:47 AM8/13/21
to Dario Pennisi, Developers
I forgot to mention.  This example from the arduino github



Explicitly says in the body of the code:

"
The circuit:
- Arduino MKR WiFi 1010 or MKR1000
"


> Question Can it work with MKR 1010 and/or MKR 1000?
>Answer Yes, both MKR WiFi 1010 and MKR 1000, just use this example sketch instead


Are you saying this code for the MKR1000 is known not to work?  If so, why is the original author saying it does?  

John Davis

unread,
Aug 13, 2021, 6:14:16 PM8/13/21
to Dario Pennisi, Developers
Btw I think I understand why you said the crypto chip is not the mkr1000.  The individual IC as a standalone is indeed not on the pcb.  However the crypto core is included in the cpu SOC.  

Dario Pennisi

unread,
Aug 14, 2021, 2:02:59 AM8/14/21
to John Davis, Developers
Hi John,
Yes, crypto core and crypto chip are two different things. The crypto core is a piece of hw that accelerates encryption algorithms so it does faster what bearssl and other SW stacks do in software. The crypto chip is a secure key storage which also implements crypto acceleration. The added benefit as I mentioned is that the secure storage allows you to preserve keys and certificates from malicious attackers.

Dario

John Davis

unread,
Aug 14, 2021, 9:26:17 AM8/14/21
to Dario Pennisi, Developers
Hello Dario,

Comments inline

On Sat, Aug 14, 2021 at 02:02 Dario Pennisi <d.pe...@arduino.cc> wrote:
Hi John,
Yes, crypto core and crypto chip are two different things. The crypto core is a piece of hw that accelerates encryption algorithms so it does faster what bearssl and other SW stacks do in software.


Yes indeed. I was looking at the data sheet.  If I understand correctly it encrypts/decrypts with its private key.

I suppose one weak point is that I’m unsure if I have manipulated the key it generated when I ran the example jws self signed certificate.

I also want to see if I can get a match betwernnsome byte sequence in code with the wireshark capture 

John 

Dario Pennisi

unread,
Aug 14, 2021, 10:31:23 AM8/14/21
to John Davis, Developers
Hi John,
When you ran the jet example nothing can have happened because the key is supposed to be stored in a chip it's not there. It failed because the i2c transactions failed hence the key was just dropped. 

Regarding wireshark, there's little chance you can compare anything after the SSL session is started because everything is encrypted wirh a random number that's different each time... One of the good reasons for this is that replay attacks should not work hence if you see two equal sessions it means something got very wrong 

Once again, server will send its certificate and after that everything will be encrypted so you should not be able to understand what's going wrong in client authentication unless you can decrypt the traffic. 

In any case it's useless to try gcp or Amazon with mkr1000... Not at least with the code you're using. You can try with mkr GSM but you'd need to load server root ca in modem using one of the examples and then load client certificate in crypto... Only at that Point you'll be able to test gcp with it...

Dario

John Davis

unread,
Aug 15, 2021, 5:13:43 PM8/15/21
to Dario Pennisi, Developers
Hello Dario,

I'm sorry you keep telling me the mkr1000 does not have a crypto chip, but I did some digging and I think it is there.

I stand corrected on the module as one monolithic SoC.  The module is advertised as two SoC's the CPU and the winc1500 wifi utility.  Optionally it has the crypto ic on the I2C bus.  I've included some screenshots of the schematics and photograph of my particular mkr1000.

The problem is that I have not been able to find a datasheet of the IC in full detail.  Ive found a summary datasheet.  With that said it has the following quote regarding the difference between the one on the board and a compatible model.

```
The Info command DevRev mode now returns 0x1005 for ATECC108A and 0x5000 for
ATECC508A. This value should not be used in the software as it will vary with each minor
revision.
```
I don't know the I2C bus address for the device.  I don't know all the commands that can be sent via I2C.  However, that 0x5000 is telling.  The constructor for the ArduinoECCX08 class has a check in the Version() call.  One of the choices to enable this driver looks for a 0x050000.  Not quite the same, but it might be some sort of byteswap or endianess to be off a zero.

With that said, I mentioned previously I had used the random() routine to see if it was there.  I added the following code:

```
void test_crypto() {
  Serial.print("GCP-Mqtt.ino->test_crypto(): ECCX08.random(5)");
  // verify result is less than 5
  Serial.println(ECCX08.random(5));
  Serial.print("GCP-Mqtt.ino->test_crypto(): ECCX08.random(10)");
  // verify result is less than 10
  Serial.println(ECCX08.random(10));
  Serial.print("GCP-Mqtt.ino->test_crypto(): ECCX08.random(100)");
  // Verify result is less than 100
  Serial.println(ECCX08.random(100));

  Serial.print("GCP-Mqtt.ino->test_crypto(): ECCX08.serialNumber(100)");
  Serial.println(ECCX08.serialNum
```

When that code runs it generates output like this:

```
GCP-Mqtt.ino->test_crypto(): ECCX08.random(5)4
GCP-Mqtt.ino->test_crypto(): ECCX08.random(10)2
GCP-Mqtt.ino->test_crypto(): ECCX08.random(100)3
GCP-Mqtt.ino->test_crypto(): ECCX08.serialNumber(100)01236BDFB66C3F0BAF
```

I added some code to print the before and after JWT encrypted by this device.  The result is:

```
The first 10 bytes of encrypted JWT from the ECCX008JWS.sign() as hex 
65 79 4A 68 62 47 63 69 4F 69
Lenght of encrypted JWT from the ECCX008JWS.sign() 202
```

So you are correct, you can't see this in packet capture.  I thought, it might be encrypted here and then put on wire as is.  That's not the case.  When I look at the capture of the first frame sent after the ciper change spec frame, it is a TLS encrypted MQTT frame.  Knowing that the frame will have a blank user, "JWT" and then this token and other headers I imagine it will be in same order of magnitude as the length above.  The length of the token above is 202.  The only tls/mqtt payload is around 300.  However, you are correct, I can not find any matching bytes.  I imagine the stack or the WINC1500 does the encryption.   Searching the hex dump of the frame and there are no substring matches.  ie. I don't see a 65 79 4A in the encrypted frame.

Other things to note, the createJWT() routine uses ~/Arduino/libraries/ArduinoECCX08/src/utility/ECCX08JSW.cpp encrypts this text differently each time.  Perhaps the time string included in the decode has that effect since its always different.

Anyway with that said, I still think the crypto chip is there.  I don't think that is the problem.  I think the problem is with the firmware/certification update utility and the cert from google.

The google tutorial mentions loading the cert using the above tool:

```
If you're using Genuino boards like the MKR1000, you will need to add SSL certificates to your board as described on Hackster.io. The MQTT server address is mqtt.googleapis.com and the port is either 8883 for most cases or 443 in case your device is running in an environment where port 8883 is blocked. For long-term support, the server is mqtt.2030.ltsapis.goog.

In future versions of this library, the MQTT domain and certificates will be changed for long term support (LTS) to:

MQTT LTS Domain - mqtt.2030.ltsapis.goog
Primary cert - https://pki.goog/gtsltsr/gtsltsr.crt
Backup cert - https://pki.goog/gsr4/GSR4.crt
```

The hackster.io link is pointing to an older version of the utility.  Understandable.  This is an old webpage.  The problem I believe is that the utility can use the mqtt.googleapis.com:8883 domain, but it can't use the long term solution domain.
When you try to use mqtt.2030.ltsapis.goog:8883 in the utilty it says " Must have RSA Public key".

Dumping the cert from linux for the two urls/domains:

```
$ openssl s_client -connect mqtt.2030.ltsapis.goog:8883
... stuff snipped
Peer signature type: ECDSA
... stuff snipped
```
versus

```
$ openssl s_client -connect mqtt.googleapis.com:8883
... stuff snipped
Peer signature type: RSA-PSS
... stuff snipped
```
The ECDSA might be why that domain cert can not me loaded.  Then again, perhaps this is not a domain cert.  I don't understand the difference between the two. ie. mqtt.2030.ltsapis.goog and mqtt.googleapis.com


So google also lists the primary and backup cert urls which end in .crt.  Perhaps that file can be downloaded and used manually?  Is it possible to load a cert from a file rather than a url?  Is it loaded in the Wifi winc1500 or the crypto chip?





Message has been deleted

Dario Pennisi

unread,
Aug 16, 2021, 4:49:41 AM8/16/21
to Developers, dav...@gmail.com, Developers, Dario Pennisi
Hi John,
i have to apologize. my knowledge of the MKR1000 is worse than yours apparently. I was checking the module documentation and schematics and didn't see it but it's actually built in the radio module so yes, it should work provided certificates are loaded in the proper positions.
to recap what you need to do is:
1) load the client certificate in the crypto chip. this can be done by following the tutorial in here (Securely Connecting a MKR GSM 1400 to Google Cloud IoT Core - Arduino Project Hub) especially the section "Configuring and Adding the Board to GCP IoT Core", which I understand you tested and it failed. if this is the case probably what's happening is that the chip has already been provisioned somehow and its configuration has been locked so if this is the case you may not be able to reconfigure it. if this step doesn't work there's no chance you'll be able to connect. note also that since the configuration of the crypto is irreversible, once you configure it for this method it won't be usable otherwise. following examples require you to store the key in slot 0 so if you chose to store it elsewhere you need to modify the examples
2) load the root CA in the radio module. As i explained in a previous email this goes in a different place than the client certificate and is loaded in a different way. This can be done using the firmware/certificate updater in the IDE. Please make sure you select the right version of the module when you perform update. in there you can add the domain you want to connect to and the tool will automatically fetch the certificate chain and pick the root CA for you. 

note that step 1, if you go for google or amazon, requires changing and locking the configuration of the crypto. this can be done only once and is needed to allow fitting the certificates. now... if you locked it for google it won't be usable anymore for arduino cloud whereas if you provisioned for arduino cloud it will not change initial configuration and would still be lockable for ONE TIME ONLY. since you mentioned you have errors i'm assuming you already locked your crypto chip so at this point there's a good chance you won't be able to do much unless you know exactly how you configured it the first time. 

regarding snooping traffic, as i mentioned to prevent replay attacks traffic is encrypted with a random number which changes each time so you won't have any luck in decoding that traffic unless you know the key.

thanks,

Dario

Hello Dario,

Comments inline

Tom



Comments inline


Tom


To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
--

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
--

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.
--

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

John Davis

unread,
Aug 16, 2021, 9:53:28 AM8/16/21
to Dario Pennisi, Developers
Hello Dario,

comments inline

On Mon, Aug 16, 2021 at 4:33 AM Dario Pennisi <d.pe...@arduino.cc> wrote:
Hi John,
i have to apologize. my knowledge of the MKR1000 is worse than yours apparently. I was checking the module documentation and schematics and didn't see it but it's actually built in the radio module so yes, it should work provided certificates are loaded in the proper positions.

LOL, no worries bro.  I doubt you know less than me.   You are fine.  In fact, you are more than fine since you have taken an interest and are helping me.  I truly appreciate your time, expertise and concern.  Its a complex puzzle with a lot of things to look at.  I spent some time this weekend to learn some more about SSL and the PKI mechanism.  I'm still learning but I am beginning to understand more.  So, with that said, you and the others I have talked with regarding this problem have helped me in that regard.  I appreciate you and all the folks looking into this.

 
to recap what you need to do is:
1) load the client certificate in the crypto chip. this can be done by following the tutorial in here (Securely Connecting a MKR GSM 1400 to Google Cloud IoT Core - Arduino Project Hub) especially the section "Configuring and Adding the Board to GCP IoT Core", which I understand you tested and it failed. if this is the case probably what's happening is that the chip has already been provisioned somehow and its configuration has been locked so if this is the case you may not be able to reconfigure it. if this step doesn't work there's no chance you'll be able to connect. note also that since the configuration of the crypto is irreversible, once you configure it for this method it won't be usable otherwise. following examples require you to store the key in slot 0 so if you chose to store it elsewhere you need to modify the examples


Hmm. I agree the client cert needs to be loaded.  Its buried in the questions and emails, but I did mention once to someone if we need the certs loaded in the firmware before we created a public key.  The first time I made a public key, I did so with just
the arduino domain cert loaded by default.  I re-created a new public key using the guide/url/section you mentioned above after loading the mqtt.googleapis.com cert.  I really thought that might be the solution.  Turns out it did not.  I'm not certain how exactly the winc1500 certs come into play with the microchip eccx08 crypto chip.

As for the locking and irreversable bit, mine is not locked.  My understanding is that it does not matter.  I have not locked mine.

Regarding the slot specified when running the sketch to create the public key, I chose 0 as the slot.  In the arduino gcp iot mk1000 example, the code uses slot zero.   So at least that lines up correctly.

// utility/ECCX08JWS.h
// sign(slot, header, payload)
return ECCX08JWS.sign(0, JSON.stringify(jwtHeader), JSON.stringify(jwtClaim));




 
2) load the root CA in the radio module. As i explained in a previous email this goes in a different place than the client certificate and is loaded in a different way. This can be done using the firmware/certificate updater in the IDE. Please make sure you select the right version of the module when you perform update. in there you can add the domain you want to connect to and the tool will automatically fetch the certificate chain and pick the root CA for you. 


Yes, and this is the point I am worried about in the previous email.  

When using the firmware updater I tried to load the following domains:mqtt.googleapiscom:8883  

o google.com:443                             
<-  This one loads in the fw updater utility and is required for the HTTPS sample to connect to https://www.google.com

o mqtt.googleapiscom:8883              
<- This one loads in the fw/cert update utility and is the one used in the sample:
  
o mqtt.2030.ltsapis.goog:8883          
<- This one failed to upload.  The error dialog said a cert must have a RSA public key.  In the previous email I showed the different key type between the two mqtt cert domains using openssl.  Its also why I was wondering about loading this cert manually.  ie. perhaps massage it to be in proper form and then load the result via the sketch

 
note that step 1, if you go for google or amazon, requires changing and locking the configuration of the crypto. this can be done only once and is needed to allow fitting the certificates. now... if you locked it for google it won't be usable anymore for arduino cloud whereas if you provisioned for arduino cloud it will not change initial configuration and would still be lockable for ONE TIME ONLY. since you mentioned you have errors i'm assuming you already locked your crypto chip so at this point there's a good chance you won't be able to do much unless you know exactly how you configured it the first time. 


Hmm.  Are you sure it needs to be locked?    Perhaps you only need to lock it if you wish to secure the private key.  


 
regarding snooping traffic, as i mentioned to prevent replay attacks traffic is encrypted with a random number which changes each time so you won't have any luck in decoding that traffic unless you know the key.


Indeed.  


 
thanks,


Dario Pennisi

Hardware Development Manager

+39 335 6878904

ARDUINO.CC


| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |


This message is confidential and may be legally privileged or otherwise protected from disclosure;

you must not copy or disclose the contents of this message or any attachment to any other person.


Dario Pennisi

unread,
Aug 16, 2021, 11:53:49 AM8/16/21
to Developers, dav...@gmail.com, Developers, Dario Pennisi
Hi John,
crypto chip memory is partitioned in sectors and these are too small to store the certificates from google or amazon. in order to fit them in you have to write its configuration and lock it so that some sectors will be grouped to form a bigger sector capable of storing the certificate. 
if you ran the example that loads the client certificate you locked your crypto configuration and there's nothing you can do to roll it back.
just to be sure we're talking about the same thing you should run this sketch:  ArduinoECCX08/ECCX08JWSPublicKey.ino at master · arduino-libraries/ArduinoECCX08 (github.com)

as you can see at line 34 ( https://github.com/arduino-libraries/ArduinoECCX08/blob/ee4523d7802fdc4fc9347d2794bd9411ab1c1cbb/examples/Tools/ECCX08JWSPublicKey/ECCX08JWSPublicKey.ino#L34 ) it asks you if you want to lock the crypto. if this message doesn't come up it means it's already locked.

if you don't run this sketch and don't lock it there's no way it can work with GCP or AWS.

it doesn't matter if you create the client cert before or after loading the SSL cert in the wireless modem but you have to do both.

if you are unsure about the certificates and want to use ltsapis i would suggest to use the command line tool from this version (https://github.com/arduino/arduino-fwuploader/releases/tag/0.1.2) that will allow you to load the certificate files from here:

the reference for the command line utility is here: certificates flash - Arduino Firmware Uploader

please remember to load the client certificate you generated to GCP as otherwise you'll be rejected.

thanks,

Dario

John Davis

unread,
Aug 16, 2021, 2:03:58 PM8/16/21
to Dario Pennisi, Developers
Hello Dario



On Mon, Aug 16, 2021 at 11:53 Dario Pennisi <d.pe...@arduino.cc> wrote:
Hi John,
crypto chip memory is partitioned in sectors and these are too small to store the certificates from google or amazon. in order to fit them in you have to write its configuration and lock it so that some sectors will be grouped to form a bigger sector capable of storing the certificate. 
if you ran the example that loads the client certificate you locked your crypto configuration and there's nothing you can do to roll it back.
just to be sure we're talking about the same thing you should run this sketch:  ArduinoECCX08/ECCX08JWSPublicKey.ino at master · arduino-libraries/ArduinoECCX08 (github.com)

as you can see at line 34 ( https://github.com/arduino-libraries/ArduinoECCX08/blob/ee4523d7802fdc4fc9347d2794bd9411ab1c1cbb/examples/Tools/ECCX08JWSPublicKey/ECCX08JWSPublicKey.ino#L34 ) it asks you if you want to lock the crypto. if this message doesn't come up it means it's already locked.


When I ran it, it asked to lock, I said no.

if you don't run this sketch and don't lock it there's no way it can work with GCP or AWS.


Hmm

it doesn't matter if you create the client cert before or after loading the SSL cert in the wireless modem but you have to do both.

if you are unsure about the certificates and want to use ltsapis i would suggest to use the command line tool from this version (https://github.com/arduino/arduino-fwuploader/releases/tag/0.1.2) that will allow you to load the certificate files from here:


Hmm that is an older version of the firmware cert update tool.  I avoided that since I thought it had to be paired with the firmware revision.  I’ll try that version since it can load files.  Thanks for the tip.


the reference for the command line utility is here: certificates flash - Arduino Firmware Uploader

please remember to load the client certificate you generated to GCP as otherwise you'll be rejected.


Yes indeed

thanks,

Dario


Thank you again

John

Dario Pennisi

unread,
Aug 16, 2021, 3:06:28 PM8/16/21
to John Davis, Developers
Hi John,
If you don't lock the crypto there's no chance it'll work... 

Tom Igoe

unread,
Aug 17, 2021, 1:59:48 PM8/17/21
to devel...@arduino.cc
Sorry to have dropped out of the conversation, John, but with Dario in the conversation you are in good hands.

One thing to add though,  in case it's any help: I have occasionally had MQTTS connection issues on a test.mosquitto.org and try.shiftr.io when connecting from both Arduinos and from my laptop. So even after you get the certs sorted on the MKR1000, you may still run into issues. I've found shiftr.io to be a little more reliable of the two.

Tom  

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

John Davis

unread,
Aug 17, 2021, 2:21:32 PM8/17/21
to devel...@arduino.cc

Hello Tom

I did not work on the arduino last night.  I instead studied on SSL.

I’m hesitant on locking the device, since I only have one.  I want to make sure I understand what I’m doing before that.  I’ll provide an update soon.  

John

Dario Pennisi

unread,
Aug 17, 2021, 5:31:23 PM8/17/21
to Developers
Hi John,
I suggest you register mkr1000 on arduinoiotcloud.... Through the guided wizard it will automatically perform crypto chip provisioning and create a base software that will allow you sending data to Arduino visualizing that through a dashboard.

You can start from here: https://create.arduino.cc/iot/devices

Thanks,

Dario

John Davis

unread,
Aug 24, 2021, 8:50:56 AM8/24/21
to Developers
Hello

I found the error with my setup/configuration.  I was using the "project name" in the arduino_secrets.h instead of the "project id".  The project name is just a name. ie. sample_project.  The project_id is of form "sample_project-somenumbers"

I am pretty sure I tried that earlier, but some other error was to blame.

With this change, the arduino example which uses the crypto chip works and the google example which does not use the crypto chip and instead uses software also works.

I am still updating my notes https://github.com/netskink/ssl_publy.

I'll eventually edit to make it more concise and to the point. 

Thanks for your help 

Reply all
Reply to author
Forward
0 new messages