Arduino IoT security libraries?

685 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