112, which can be wireless and/or wired, that enable the microcontroller 110 to communicate with a network (e.g., the Internet). For instance, the microcontroller 110 can include a Wi-Fi communication module that can be used to communicate with one or more external communication endpoints 108-1, 108-n via a wireless connection. In view of the optional communication modules 112 included on the microcontroller 110, the microcontroller can be interchangeably referred to herein as microcontroller 110 or server 110.

As depicted in FIG. 1, in the formation of a TLS connection, the first internal communication endpoint task 106-1 can initiate a handshake request 104-1 with the TLS stack 110, which is depicted as including a handshake manager task 114, secure communication crypto op handler task 116, handshake memory 118, and session cryptography functions stack 122. In some embodiments, the handshake request 104-1 can be initiated over a network and transferred to the TLS stack 128 via the internal communication endpoint task 106-1, as discussed herein. In some embodiments, the TLS stack 128 can include a handshake manager task 114, which can be instructions stored on a memory (e.g., non-volatile memory) included on the microcontroller and can be executed by the processor 124. As further depicted in FIG. 1, the second internal communication endpoint task 106-n can also initiate a handshake request 104-n with the TLS stack 128. In some embodiments, the first handshake request 104-1 and the second handshake request 104-n can be initiated at the same time. In some embodiments, one of the handshake requests 104-1, . . . , 104-n can be initiated after beginning to authenticate the other one of the handshake requests.

In some embodiments, the order to request processing depends on the arrival time of requests if they were initiated from an external communication endpoint and/or priority of the internal communication endpoint tasks. In an example, the prioritization can be based on a timestamp and/or application priority. For instance, if two TLS requests arrive at the same time, one for a first application and another one for a second application, and the first application task has higher priority than the second application task, then an operating system of the microcontroller will schedule the first application task first, because it has a pending event (socket connection) and when the first application processes the socket connection, it will queue the message to the handshake manager task 114 task. Once that is done, the operating system of the microcontroller will schedule the second application, because it has a pending event (socket connection) and when the second application processes the socket connection, it will queue the message to the handshake manager task 114. Once that is done, the operating system will schedule the handshake manager task 114 and it will look through its queue and handle it in first in, first out fashion. Since in this particular example, there are two messages associated with the first application and second application, the message from the first application will be handled first, because it was queued first.

Upon receipt of the first handshake request 104-1, the handshake request can be received by a handshake manager task 114. In some embodiments, the handshake manager task 114 can prioritize memory resources with respect to performance of the first series of authentication steps associated with the first handshake request 104-1, as further discussed herein, until the first series of authentication steps have been completed. The handshake manager task 114 can schedule authentication actions associated with each handshake request 104. For instance, as depicted, in FIG. 1 the first handshake request 104-1 can be received at a same time as the second handshake request 104-2. As a result, the handshake manager 114 can hold the second handshake request 104-n in a queue until processing associated with the authentication steps for the first handshake request 104-1 are complete. As a result of holding the second handshake request 104-n in a queue until the processing associated with the first handshake request 104-1 is complete, the handshake memory 118 resources can be preserved, preventing overutilization of the handshake memory 118 resources of the microcontroller, on what can already be a resource constrained device.

In some embodiments, a first series of authentication steps, as further discussed herein, can be performed with the microcontroller 110, related to the first transport layer security request. In some embodiments, the handshake manager task 114 and the secure communication crypto op handler task 116 can be instructions stored in a non-volatile memory of the microcontroller 110 and can be executed by the processor 124, performing the authentication steps (e.g., authentication operations). Operations associated with processing the handshake request 104-1 can be performed on the handshake memory 118. For example, the first series of authentication steps with the TLS stack 128 can be performed using the handshake memory 118 associated with the TLS stack 128 to perform the first series of authentication steps. In some embodiments, all of the handshake memory 118 can be dedicated to performing the first series of authentication steps.

As depicted in FIG. 1, the handshake manager task 114 is used to exchange all the TLS handshake messages related to the current connection, establish asymmetric keys (public/private keys), validate certificates against root of trust as well as validate connection messages and create session keys used during the secure communication stage. The secure communication crypto op handler task 116 can perform cryptographic operations (e.g., authentication steps) associated with the TLS request to provide secure communications between the internal communication endpoints 106-1, 106-n and the external communication endpoints 108-1, 108-n. For example, the secure communication crypto op handler 116 can use asymmetric keys, established during the handshake, to encrypt and/or decrypt application messages exchanged during the secure connection stage.

In response to completion of the first series of authentication steps with the handshake manager task 114, a determination can be made of whether to establish a secure connection between the internal communication endpoints 106-1, 106-n and a respective one of the external communication endpoints 108-1, 108-n. As depicted, the handshake manager task 114 can communicate with the secure communication crypto op handler task 116 in performing the authentication steps associated with the handshake requests 104-1, 104-n. In some embodiments, in response to completing the first series of authentication steps, a determination can be made with the TLS stack 128 that credentials of the external communication endpoint 108-1, . . . , 108-n are trusted and a secure connection can be made.

Pending a determination that a secure connection can be made, session keys can be created by the TLS stack 128 (e.g., the handshake manager task 114). Thus, the communication between the first internal communication endpoint 106-1 and the first external communication endpoint 108-1, for example, can enter a secure connection stage, which utilizes a first session memory 120-1 of the internal communication endpoint task 106-1 and the session cryptography functions stack 122 and no longer utilizes the handshake memory 118. In the secure connection stage, communication can occur between the internal communication endpoints 106-1, . . . , 106-n and the external communication endpoints 108-1, . . . , 108-n via decrypt/encrypt application messages 126-1, using the session keys generated in the performance of the authentication steps.

As mentioned, the amount of memory needed for subsequent communications, post authentication steps, can be much less than the memory needed for performing the authentication steps. Accordingly, the session memory 120 and the session cryptography functions stack 122 can be used for subsequent communications, in parallel, between all authenticated communication endpoints. For example, as depicted, upon authentication of the first external communication endpoint 108-1 and/or second external communication endpoint 108-n, the external communication endpoints 108-1, 108-n can communicate with the internal communication endpoints 106-1, 106-n via decrypt/encrypt application message 126-1, 126-n. In response to decryption/encryption of an application message, data can be processed 132-1, 132-n.

In some embodiments, as discussed herein, the handshake memory 118 can be memory that is used for authentication steps that are performed during a handshake stage. The handshake memory can include memory that stores public and/or private keys, memory that stores Public Key Infrastructure (PKI) algorithms, and/or memory that stores certificates and/or parts of certificates that can be needed for authentication.

Completion of the first series of authentication steps can result in a determination that the credentials of the first external communication endpoint 108-1 can be trusted and/or untrusted, depending on the operations completed by the handshake manager task 114. In some embodiments, in response to completion of the first series of authentication steps, the handshake memory 118 can be released and no longer used and the handshake manager task 114 can schedule authentication actions to be completed for the second handshake request 104-n on the handshake memory. In an example, the second series of authentication steps with the second internal communication endpoint task 106-n related to the second transport layer security request initiated with the second external communication endpoint 108-n can include performing the second series of authentication steps in response to formation of the secure connection between the first external communication endpoint 108-1 and the internal communication endpoint 106-1, as a result of determining that the credentials of the first external communication endpoint 106-1 are trusted.

In a further example, the second series of authentication steps with the second internal communication endpoint 106-n related to the second transport layer security request can include performing the second series of authentication steps in response to termination of any prospective connection between the first external communication endpoint 106-1 and the internal communication endpoint 106-1, as a result of determining that the credentials of the first external communication endpoint 108-1 are untrusted. Either way, upon a determination that the credentials of the first external communication endpoint 106-1 are trusted or untrusted, the handshake memory 118 used in the determination can be released and no longer used, as the authentication steps associated with the handshake request 104-1 can be completed, resulting in determination of a trusted or untrusted connection and handshake complete 134-1, 134-n. As such, operations associated with only one handshake request 104-1 can be performed using the handshake memory 118 at any one time to prevent the handshake memory 118 from being overutilized.

In some embodiments, in response to completion of the first series of authentication steps, a second series of authentication steps related to the second transport layer security request can be performed with the TLS stack 128. In a similar or same manner to that discussed above in relation to the first external communication endpoint 106-1 and the first transport layer security request, a second series of authentication steps can be performed with the TLS stack 128, related to the second transport layer security request. For example, the second transport layer security request can be held in a queue, until the determination whether to establish the secure connection between the first external communication endpoint 108-1 and the first internal communication endpoint 106-1, in response to completion of the first series of authentication steps is made. Upon completion of the determination, all of the handshake memory 118 can be made available to processing the second transport layer security request.

As discussed, operations associated with processing the second handshake request 104-n can be performed on the handshake memory 118. For example, the second series of authentication steps with the second internal communication endpoint 106-n can be performed using the handshake memory 118 associated with the server 110. In some embodiments, all of the handshake memory can be dedicated to performing the second series of authentication steps, in response to completion of the first series of authentication steps.

As depicted in FIG. 1, the handshake manager task 114 can perform cryptographic operations associated with the second TLS request (e.g., handshake request 104-n) to provide secure communications between the second external communication endpoint 108-n and the second internal communication endpoint 106-n. Although the internal communication endpoint 106-n is referred to as second internal communication endpoint 106-n, there can be any number of internal communication endpoints “n” attempting to perform handshake requests with the TLS stack 128. The handshake manager task 114 can use an asymmetric key (e.g., public/private key cryptography) to validate a certificate against a root of trust. The handshake manager task can further create session keys (e.g., symmetric cryptography) that are used to encrypt/validate messages in a “secure connection” stage, which happens after the handshake request 104-n has been processed.

In response to completion of the second series of authentication steps with the handshake manager task 114, a determination can be made of whether to establish a secure connection between the second external communication endpoint 108-n and the second internal communication endpoint 106-n in response to completion of the second series of authentication steps. In some embodiments, in response to completing the second series of authentication steps, a determination can be made with the TLS stack 128 that credentials of the second external communication endpoint 108-n are trusted and a secure connection can be made. Pending a determination that a secure connection can be made, session keys can be created by the second external communication endpoint 108-n and the TLS stack 128 (e.g., handshake manager task 114). Thus, the communication between the second external communication endpoint client 108-n and the internal communication endpoint can enter a secure connection stage, which utilizes session memory 120 and no longer utilizes the handshake memory 118.

For example, completion of the second series of authentication steps can result in a determination that the credentials of the second external communication endpoint 108-n are trusted and/or untrusted, depending on the operations completed by the handshake manager task 114. In some embodiments, in response to completion of the second series of authentication steps, the handshake memory 118 can be released and no longer used for the second series of authentication steps and the handshake manager task 114 can schedule authentication actions to be completed for a next handshake request that is received, on the handshake memory 118. In an example, a next series of authentication steps with the internal communication endpoint related to the next transport layer security request includes performing the next series of authentication steps in response to formation of the secure connection between the second external communication endpoint 108-n and the second internal communication endpoint 106-n as a result of determining that the credentials of the second external communication endpoint 108-n are trusted.

In a further example, the next series of authentication steps with the internal communication endpoint related to the next transport layer security request includes performing the next series of authentication steps in response to termination of any prospective connection between the second external communication endpoint 108-n and the second internal communication endpoint 106-n as a result of determining that the credentials of the second external communication endpoint 108-n are untrusted. Either way, upon a determination that the credentials of the second external communication endpoint 108-n are trusted or untrusted, the handshake memory 118 used in the determination can be released and no longer used for the determination specific to the second internal communication endpoint 106-n. As such, operations associated with only one handshake request 104-1, 104-n can be performed using the handshake memory 118 at any one time to prevent the handshake memory 118 from being overutilized.

Although two external communication endpoints are depicted in FIG. 1, including first external communication endpoint and n (e.g., second) external communication endpoint, any number “n” of external communication endpoints 108 can be present. For example, ten or more external communication endpoints can be present in some instances and can be dependent on how many external communication endpoints are trying make an initial communication with the internal communication endpoint 106. For example, in some embodiments, ten or more external communication endpoints may simultaneously try to communicate with the internal communication endpoints 106 and thus the handshake manager task 114 may put all but one of the associated authentication requests in a queue. For example, the handshake manager task 114 may only allow one of the transport layer security requests to be processed at any one time, while holding the remaining transport layer security requests in queue. As discussed, the remaining transport layer security requests can be held in queue until the first transport layer security request is processed and then each consecutive transport layer security request is processed.

In some embodiments, more than one of the transport layer security requests can be processed at any one time. For example, in some embodiments, where a plurality of transport layer security requests (e.g., 10 transport layer security requests are received), a number of transport layer security requests that is greater than one, but is less than the overall number of transport layer security requests, can be processed at any one time. In an example, multiple ones of the transport layer security requests can be processed at any one time, while a remaining number of the transport layer security requests are held in a queue. For instance, two transport layer security requests can be processed at any one time, while the remaining 8 transport layer security requests are held in queue until one or both of the two initial transport layer security requests are processed. Thus, some embodiments can allow for multiple ones of the transport layer security requests to be processed (e.g., 2, 3, etc.) at any one time, thereby balancing the use of handshake memory resources used by the server 110 with initial wait times for processing of the transport layer security requests.

In some embodiments, an order for associated processing of the transport layer security requests can be dependent on a time stamp for when each of the transport layer security requests was received. In some embodiments, additionally or in the alternative, the order for associated processing of the transport layer security request can be dependent on a priority of the application task that is supposed to handle the payload data after the connection is established In some embodiments, the order for associated processing of the transport layer security requests can be based on an internal communication endpoint task priority associated with each transport layer security request. In some embodiments, the order for processing of the transport layer security requests can initially be based on a time stamp for when each of the transport layer security requests was received. If a time stamp for one or more of the transport layer security requests is the same as or similar to another one of the received transport layer security requests, then the transport layer security requests with the same or similar time stamp can be prioritized in terms of processing, based on an internal communication endpoint task priority associated with each transport layer security request.

In some embodiments, a priority can be based on a service the task is supposed to handle. For example if 2 servers running in the device (e.g. HTTPS and Secure Fieldbus), it is assumed that Secure Fieldbus has higher priority compared to HTTPS and therefore the task that services SecFieldbus will have a higher priority than the HTTPS task. Therefore if two requests arrive at the same time (e.g., one for SecFieldbus connection and another one for HTTPS connection, the application task for SecFieldbus will be invoked first (due to its priority) and it will queue the connection request to the handshake manager task 114 first.

FIG. 2 depicts a system 142 utilizing TLS and hypertext transport protocol secure (HTTPS), in accordance with embodiments of the present disclosure. Embodiments depicted in FIG. 2 can include some of the same or similar features as those depicted and discussed in relation to FIG. 1. In some embodiments, a first handshake request (e.g., TLS security request) 144-1 can be received from a first internal communication endpoint task 146-1. As further depicted in FIG. 1, an additional (e.g., second) handshake request 144-n can be received from a second internal communication endpoint task 146-n. In some embodiments, the second internal communication endpoint task 146-n can be representative of an HTTPS server, as depicted. Accordingly, the second handshake request 144-n can be associated with a HTTPS request, and in some embodiments can be initiated by an external communication endpoint task 148-2, which can be representative of a web browser, for example. Although both a first internal communication endpoint task 146-1 and a second HTTPS server internal communication endpoint task 146-n are depicted in FIG. 2, each of the internal communication endpoint tasks 146-1, 146-n can include an application task, each of the internal communication endpoint tasks 146-1, 146-n can include HTTPS requests, or each of the internal communication endpoint tasks 146-1, 146-n can include a mix of application tasks and HTTPS server request handlers, as depicted.

As depicted in FIG. 2, the secure communication crypto op handler task 156 can perform cryptographic operations associated with the first handshake request 144-1 to provide secure communications between the first external communication endpoint task 148-1 and the microcontroller 150, allowing for communication between the two via decrypt/encrypt application message 172-1, 172-n. The secure communication crypto op handler task 156 can further use session keys (e.g., symmetric cryptography) that are used to encrypt/validate messages in a “secure connection” stage, which happens after the handshake request 144-1 has been processed and utilizes a session memory 160 and the session cryptography functions stack 162 and no longer utilizes the handshake memory 158.

In response to completion of the first series of authentication steps with the handshake manager task 154, which can be instructions stored on a memory of the microcontroller 150 and executable by the processor 164, a determination can be made of whether to establish a secure connection between the internal communication endpoints 146-1, 146-n and a respective one of the external communication endpoints 148-1, 148-n. In some embodiments, in response to completing the first series of authentication steps, a determination can be made with a TLS stack 178 that credentials of the first external communication endpoint 148-1 are trusted and a secure connection can be made. Pending a determination that a secure connection can be made, session keys can be created by the TLS stack 178 (e.g., the handshake manager task 154). Thus, the communication between the first internal communication endpoint task 146-1 and the first external communication endpoint 148-1, for example, can enter a secure connection stage, which utilizes a first session memory 160-1 of the first internal communication endpoint task 146-1 and no longer utilizes the handshake memory 158.

In some embodiments, a determination can be made that the credentials of the first external communication endpoint task 148-1 are untrusted, as discussed herein. Either way, upon a determination that the credentials of the first external communication endpoint task 148-1 are trusted or untrusted, the handshake memory 158 used in the determination can be released and no longer used, as the authentication steps associated with the handshake request 144-1 can be completed, resulting in determination of a trusted or untrusted connection and handshake complete. As such, operations associated with only one handshake request 144-1 can be performed using the handshake memory 158 at any one time to prevent the handshake memory 158 from being overutilized.

As depicted, the second internal communication endpoint task n 146-n can include an HTTPS request. In establishing communication between the second internal communication endpoint task 146-n and the microcontroller 150, authentication actions can be performed, as discussed herein. For example, the secure communication crypto op handler task 156 can perform cryptographic operations associated with the second TLS request 144-n to provide secure communications between the internal communication endpoints 146-1, 146-n and the external communication endpoints 148-1, 148-n. For example, the secure communication crypto op handler task 156 can use a symmetric keys, established during the handshake, to encrypt and/or decrypt application messages exchanged during the secure connection stage. In response to decryption/encryption of an application message, data can be processed 176-1, 176-n.

In response to completion of the second series of authentication steps with the handshake manager task 154, a determination can be made of whether to establish a secure connection between the second external communication endpoint task 148-n and the HTTPS server internal communication endpoint task 146-n, in response to completion of the second series of authentication steps. In some embodiments, in response to completing the second series of authentication steps, a determination can be made with the TLS stack 178 (e.g., handshake manager task 154) that credentials of the second external communication endpoint task 148-n are trusted and a secure connection can be made.

Since the handshake memory 158 is used to process the authentication steps associated with the second handshake request 144-n, the handshake manager task 154 can continue to provide access to the handshake memory 158 so it can be used in processing the HTTPS request. In some embodiments, an HTTP request can be received from the second external communication endpoint task 148-n, upon performing the second series of authentication steps associated with the second external communication endpoint task 148-n. In an example, the HTTP request can include a request to share static data with the second external communication endpoint task, which can include HTML files, JavaScript, graphics (e.g., .jpeg files, etc.). Because the handshake memory 158 is still made available by the handshake manager task 154, the HTTP request can be parsed with the handshake memory 158 of the TLS stack 178 and static data can be provided to the second external communication endpoint 148-n. In some embodiments, the handshake memory 158 can be released upon parsing the HTTP request and providing the static data to the second external communication endpoint 146-n, or dynamic data as further discussed herein.

In some embodiments, two types of HTTPS connections can be associated with embodiments of the present disclosure. A first type of HTTPS connection can involve the exchange of static data. For example, an HTTP request can request static files, where a client establishes a TLS connection and the client sends a request for static files. A server can parse the request for static files and send back the desired file, which can be encrypted using session keys. Upon completing the request, the server can close the connection with the client. In this example, an associated handshake memory can handle establishing the TLS connection, sending the request for static files, and parsing the request. A second type of HTTPS connection can involve the exchange of dynamic data. For example, a client can establish a TLS connection and the client can send a request to upgrade the connection to a WebSocket connection. In response, the server can parse the request and send back a response that the connection has been upgraded to WebSockets (e.g., encrypted using session keys). The client can then send a first WebSocket request, which can be encrypted using session keys. In response, the server can send a first WebSocket response (e.g., encrypted using session keys). In response, the client can close the connection or keep the connection active to perform multiple WebSocket exchanges. In the example using dynamic data, the handshake memory can handle establishing the TLS connection, sending a request to upgrade the connection to a WebSocket connection, and parsing the request, since the client request could be large.

In some embodiments, an HTTP request can be received by the second internal communication endpoint task 146-n from the second external communication endpoint task 148-n, upon performing the first series of authentication steps. The HTTP request can include a request to share dynamic data with the second external communication endpoint task 148-n and a request to switch protocols for additional handling of dynamic data. In an example, a protocol that can be used for the transfer of dynamic data can be WebSockets. In some embodiments, dynamic data can include input/output data, configuration data, and/or network settings (e.g., IP addresses, Profinet device name), and can be provided to the second external communication endpoint task 148-n using a session memory 160-n of the microcontroller 150. In some embodiments, by using the session memory 160-n of the microcontroller 150, for the transfer of dynamic data, the handshake memory 158 can thus remain open and not used. In some embodiments, the dynamic data does not require much in terms of memory requirements for associated transfers and can be fragmented, if necessary. By using the session memory 160-n for the transfer of dynamic data, the handshake memory 158 can be used for the performance of further authentication steps associated with other clients.

As depicted in FIG. 2, in the performance of the above steps, the handshake manager task 154 can dedicate the handshake memory 158 to completion of the authentication steps. After performance of the authentication steps, rather than releasing the handshake memory 158 for use in authentication steps associated with another external communication endpoint task, the handshake manager task 154 can dedicate the handshake memory 158 for use in relation to processing the HTTPS request, as indicated by communication 168. The handshake memory 158 can then be used in processing the HTTPS request, as indicated by the line 170. For example, upon receiving the HTTP request from the second external communication endpoint task 148-n, the HTTP request can be parsed with the handshake memory 158 of the server. As depicted, the second external communication endpoint task 148-n can be associated with a web browser, in some embodiments. In the HTTPS exchange, the request that contains the most overhead can be the HTTP client request that is sent right after the authentication steps are completed.

In some embodiments, the HTTP request can be sent from the second external communication endpoint task 148-n to the second internal communication endpoint task 146-n during completion of the authentication steps and/or when the initial handshake request 144-n is sent and the HTTP request can be held in queue by the handshake manager task 154. Upon processing of the HTTP request with the handshake memory 158, the additional exchanges that later occur (e.g., exchange of dynamic data) can utilize very small amounts of memory (e.g., session memory 160). In some embodiments, the handshake manager task 154 does not release handshake memory resources right after the completion of the authentication steps associated with the handshake request 144-1 (e.g., handshake complete 174-1, 174-n), but in some embodiments, can pass the handshake memory buffer to a specific application allowing it to use the handshake buffer to complete the first exchange which requires a greater amount of memory resources. In some embodiments, that application can notify the handshake manager task 154 that it does not need the handshake buffer any longer and it can be reused by other applications to perform authentication steps (e.g., transport layer security handshake). For example, as represented by communication 170, the second internal communication endpoint task 146-n can notify the handshake manager task 154 that the handshake buffer associated with the handshake memory 158 is no longer needed for parsing of the HTTP request and the handshake memory 158 can be released for use in additional authentication steps associated with additional clients.

FIG. 3 depicts a flow diagram 180 of an exchange of static content between a browser 182 and a microcontroller server 184 utilizing TLS and HTTPS, in accordance with embodiments of the present disclosure. In some embodiments, the browser 182 can initiate a request to open a TLS connection with the server 184, in the form of a handshake request, as discussed herein, and represented by open TLS connection flow 186. As discussed herein, the browser 182 can be associated with a client computer that is desiring to interact with the server 184, which in some embodiments can be a microcontroller, as discussed herein, which includes a communication module that can provide for wireless communication via a wireless network protocol (e.g., Wi-Fi). In response to the handshake request, the server can allocate handshake memory via a handshake manager task, which can allocate all of a handshake memory associated with the server to processing the TLS request sent by the browser 182. In some embodiments, authentication operations can be performed on the handshake memory and in response to completion of the authentication operations and authentication of the credentials of the browser 182 and the server 184, a connection can be opened, as represented by connection opened flow 188.

In some embodiments, the handshake manager task does not release handshake memory resources right after the connection has been opened, but in some embodiments, can pass the handshake memory buffer to a specific application allowing it to use the handshake buffer to complete the first exchange which requires a greater amount of memory resources than subsequent communications made between the server 184 and browser 182. In some embodiments, the first exchange can include a single HTTP message sent by the browser 182 to the server 184, which can include a request to send static content from the server 184 to the browser 182, as represented by send HTTP request static content flow 190. In some embodiments, the handshake manager 154, as discussed in FIG. 2, can allow for the handshake memory 158 to parse the HTTP message and provide the static content to the browser 148-n from the HTTPS server 146-n. In response to the static content being sent to the browser, represented by send HTTP response with all static content flow 192, the connection between browser 182 and the server 184 can be closed, which can be represented by close connection flow 194. Subsequent communications between the browser 182 and the server 184 can be exchanged with smaller amounts of overhead (e.g., use of memory) than the initial amount of overhead associated with establishing the connection and processing the first HTTP request.

FIG. 4 depicts a flow diagram 200 of an exchange of dynamic content between a browser 202 and an HTTPS server 204 utilizing TLS and HTTPS, in accordance with embodiments of the present disclosure. In some embodiments, the browser 202 can initiate a request to open a TLS connection with the server 204, in the form of a handshake request, as discussed herein, and represented by open TLS connection flow 206. As discussed herein, the browser 202 can be associated with a client computer that is desiring to interact with the server 204, which in some embodiments can be a microcontroller, as discussed herein, which includes a communication module that can provide for wireless communication via a wireless network protocol (e.g., Wi-Fi). In response to the handshake request, the server 204 can allocate handshake memory via a handshake manager task, which can allocate all of a handshake memory associated with the server to processing the TLS request sent by the browser 202. In some embodiments, authentication operations can be performed on the handshake memory and in response to completion of the authentication operations and authentication of the credentials of the browser 202 and the server 204, a connection can be opened, as represented by connection opened flow 208.

In some embodiments, the handshake manager task does not release handshake memory resources right after the connection has been opened, but in some embodiments, can pass the handshake memory buffer to a specific application allowing it to use the handshake buffer to complete the first exchange which requires a greater amount of memory resources than subsequent communications made between the server 204 and browser 202. In some embodiments, the first exchange can include a single HTTP message sent by the browser 202 to the server 204, which can include a request to send dynamic content from the server 204 to the browser 202 and a request to switch to a more resource friendly protocol, as represented by send HTTP request to switch to WebSockets (WSS) 210. In an example, the request to switch protocols can be a request to switch protocols for additional handling of dynamic data. In some embodiments the request to switch protocols can include a request to switch to a WebSockets protocol for additional handling of dynamic data. The WebSockets protocol can have a small message format with no additional variable length overhead imposed by browsers. Upon switching protocols, the server 204 can send a confirmation, represented by send HTTP response WSS switch success flow 212. For example, in some embodiments, when the server 204 successfully switches to the WebSockets protocol, the server 204 can send a response that it has successfully switched to WebSockets, represented by flow 212.

Each HTTP message exchange involves a large amount of overhead and most cases when dynamic data is exchanged, the usable data occupies a very small fraction of a number of bytes exchanged. Due to the inability of the server 204 to force the client to fragment the TLS messages, all this additional protocol data can be bundled into a single TLS frame requiring the server to allocate data (e.g., 4 KB) in the HTTPS server application task. This can make it possible for the client associated with the browser 202 to control fragmentation of TLS frames as all the WebSocket frames are sent in separate TLS records.

In some embodiments, as depicted in FIG. 4, a series of WebSocket requests 214-1, . . . , 214-K for dynamic data can be sent by the browser 202 to the server 204. As further depicted, in response to the WebSocket requests 214-1, . . . , 214-K, responses can be provided to the browser, represented by send WSS Response flow 216-1, . . . , 216-K. In some embodiments, the client associated with the browser can control a connection duration between the browser 202 and the server 204, by opening the WebSocket connection and performing the needed number of exchanges. In response to the browser 202 obtaining a requisite amount of dynamic data, the browser 202 can send a request to the server 204 to close the connection between the browser 202 and the server 204. The handshake manager task can release a handshake memory right after sending the response 212 to allow other TLS connections to be established concurrently with the exchange of dynamic data in 214-1/216-1 . . . 214-K/216-K. As represented by the embodiments depicted in FIGS. 3 and 4, in some embodiments, the only HTTP request message that needs to be handled by the server 184, 204 can be for one of two reasons: a request to provide static content, as depicted and discussed in relation to FIG. 3, and/or a request to switch protocols (e.g., to WebSockets), as depicted and discussed in relation to FIG. 4.

In some embodiments, the initial message exchange after handshake can be large on some other protocols and therefore the same approach can be used, as with WebSockets. Accordingly, embodiments of the present disclosure include a mechanism where an application tells the handshake manager that it needs to service the first set of exchanges after the handshake and the handshake manager does not release the handshake memory and does not start with the next handshake until the current application notifies it to do so (e.g., when it is done with the initial set of large exchanges).

FIG. 5 depicts a method 230 flow diagram for performing authentication, in accordance with embodiments of the present disclosure. As previously discussed, the method 230 can include receiving 232, with a transport layer security stack, a plurality of transport layer security requests from a plurality of internal communication endpoint tasks, wherein the plurality of transport layer security requests are related to establishing a secure connection with a plurality of respective external communication endpoints. In some embodiments, the internal communication endpoint task can be included on a microcontroller that includes a communication module, which can enable the microcontroller to communicate with a plurality of clients, thereby acting as a server.

Oftentimes, a microcontroller can have limited memory, which can be exhausted when attempting to form secure connections with multiple ones of the plurality of external communication endpoints. Accordingly, embodiments of the present disclosure can enable the limited memory resources of the microcontroller to be managed in a way that prevents them from being overutilized. In some embodiments, the method 230 can include performing 234 a first series of authentication steps related to a first one of the plurality of transport layer security requests received from a first one of the plurality of internal communication endpoint tasks, utilizing a handshake memory of the transport layer security stack. In some embodiments, the transport layer security stack can include a handshake manager task and a handshake memory. The handshake manager task can be executed in order to create a queue when multiple handshake requests are received at any one time from multiple internal communication endpoint tasks.

In some embodiments, the method 230 can include determining 236 whether to establish a secure connection with a first one of the plurality of external communication endpoints in response to completion of the first series of authentication steps. The decision of whether to establish a secure connection with the first external communication endpoint can be based on a handshake stage where the external communication endpoint and respective internal communication endpoint verify each other's credentials using symmetric keys (e.g., public/private key cryptography). Certificates associated with the internal communication endpoint and the external communication endpoint are validated against a root of trust. Upon validation of the certificates, session keys can be created utilizing symmetric cryptography, which can be used to encrypt/validate messages in a secure connection stage.