Hi. @roneld01 and @acpie360
I have implemented a random number generator from RF noise on my board. And it is working.
I can increase the size of my buffer from 16 to 32 bytes (or even 64 if needed), in order every time I need a seed there will be 32 bytes ready to be read from that buffer. A question, the values of the individual bytes of the random data can range from 0 to 255? Or do these bytes need to be characters only?
@roneld01 Thanks so much for your help until here.
Would mbedtls_hardware_poll look like this? What should happen when “len > *olen” , whats the commomly used values for len? Can it be limited to 32?
As mentioned correctly by @acpie360 , The random buffer is a binary byte buffer, which means every byte is a buffer should have a value from 0 to 255. This is not a string
olen is the size of the actual buffer filled, and since len is the size of the buffer given as input, olen cannot exceed the length of len, but it can not be larger than what your platform can actually generate. So, your second example the correct one.
What should happen when “len > *olen” , whats the commomly used values for len?
As you can see here, the default maximal threashold value is 32. However, the value MBEDTLS_ENTROPY_MAX_GATHER ( default 128 is requested, but this is configurable) is given as len. But, if the threshold is reached or got enough entropy (can be maximal 64 bytes), then no more collection. So, if you can set the collection to 64 bytes, it would be best.
On the picture below, should I not use ‘2’? If yes, what is the correct sequence? 1-3 or 3-1?
On SERVER_NAME, I will use “abomin3v3l-3e161.firebaseio.com”, do I need to put “https://” in front?
Compiler says “undefined reference to `mbedtls_net_connect’”
Mbed Crypto already supplies this function as part of Mbed TLS. This function gathers all the entropy, and conditions it into a proper seed. This is not what you did in your implementation. Please don’t replace it unless you have a very good reason. If you replace it for some reason, you actually don’t need mbedtls_hardware_poll().
Compiler says “undefined reference to `mbedtls_net_connect’”
That’s because you have ‘MBEDTLS_NET_C’ undefined. You will need to use your own connection method to your socket, like you did in “2”
There is a difference between SERVER_NAME and SERVER_ADDR. The server name is the host name, which is also checked in the certificate. Only the name, without the protocol prefix should be set. The server_addr is the address which you connect to in your transport layer. If you can connect only with that, then this is fine, otherwise, add the prefix.
On the picture below, compiler says “undefined reference to `mbedtls_x509_crt_parse_file’”
This is because you have MBEDTLS_FS_IO undefined. If you don’t have IO functionality, you should use mbedtls_x509_crt_parse() on your CA certificate which you have in a buffer.
And I did not understood how to use that function:
As shown in the example, the chain parameter is a pointer to a mbedtls_x509_crt struct which will hold the parsed information. The path parameter is a string of the path of your certificate file
On the declaration: const char *cafile = “/path/to/trusted-ca-list.pem”;
Should I use, for instance, in place of “/path/to/trusted-ca-list.pem” use the content of c00.pem?
If you are using a file, then the cafile should point to the path, not the content. If you don’t have IO , then your deceleration should be ‘const char cafile = content of c00.pem’ as shown in the test certificate example. (For a simpler example, you can look at the Mbed-OS client example application), however it is C++ style String
Now it is compiling, and I think I just need to implement mbedtls_net_send and mbedtls_net_recv. I created a function called TLSCLose, which will be called when any error occur on rx/tx functions and also to close the communication with the server.
As I know, before sending and receiving encrypted packets we need to make a little setup before. Check my current setup below, is that sufficient? Is there something ele missing?
You are missing the entropy initialization and setup, however I am assuming it is before this code segment.
Please look at the ssl client example for the ssl configuration functions that are used, as it is dependent on what your needs in your client are.
Do you call after that mbedtls_ssl_setup()?
As for your comment:
DO I NEED THIS IF I’M CLIENT ONLY?
yes, you do. This should be the root certificate of the CA that signed your server certificate. This should be a trusted certificated, that you can set in your client, when the server sends it certificate, it is verified against your trusted certificate, to confirm the server is trusted.
If you are using baremetal, I am assuming you have RAM limitations, so I would suggest you use DER format certificates instead of PEM.
int mbedtls_hardware_poll (void *data, unsigned char *output, size_t len, size_t *olen)
data = NULL;
uint16_t i = 0;
//supply up to 64 numbers, and a maximum of 'len' bytes (requested)
while (i < ManchesterRandomNumberQty && i < len)
*(output+i) = ManchesterReadRandomNumber(DECOD_MANCHESTER());
*olen = i;
Yes, you can put it in the intial setup.
as for //TLS - CONNECTION SETUP , Note this should be done before you establish a TLS connection, not before every time you want to send/receive data to/from the server (Unless I misunderstood your sentence regarding this)
As for checking whether your code is ok, I am sorry but I cannot confirm, as we cannot be liable for your code, however in general it looks ok. You should compare with the sample application whether you missed anything else or not. and whether there are features you haven’t added.
Now, I’m in doubt on how to implement:
mbedtls_net_send(void *ctx, const unsigned char buf, size_t len )
mbedtls_net_recv(void *ctx, unsigned char *buf, size_t len)
There is no implementation of these functions of the example ssl_client2. What do I need to do with ctx?
For example, supposing I want to send a string, some function of the lib would receive my original string, then encrypt it and then send it encrypted? Maybe there are some misleading of my part here.
Let me explain a little about how my system work.
I have the PIC32MX MCU connected to an ESP-01 wifi module using one Uart/Serial, and my goal is to connect to a Firebase server and send data to it, I will give an example.
To open a websocket with the database, the MCU send string “AT+CIPSTART=“TCP”,“abomin3v3l-3e161.firebaseio.com”,443\r\n” (or it can be “AT+CIPSTART=“TCP”,“https://abomin3v3l-3e161.firebaseio.com”,443”, this will result the same) to ESP-01 module, then ESP responds “CONNECTED\r\nOK\r\n”. At this point the connection is stablished and I can send the HTTP content (header+data), but as Googles’s Firebase requires HTTPS, I need to send that data encrypted, I think here is where mbedTLS will operate.
I am simulating write to my database with Postman and it is working, and the content of my test-packet is:
PUT /January.json?auth=DZSQwLoNWAneWA9BcEfAgnelmY965pq98HF4pITU HTTP/1.1
I want to send the same content to the database, but using the MCU.
After the websocket is open with the server, if I want to send the text above, as it has 166 bytes, I need to send to the ESP-01 module:
(b) send the content, 166 bytes, and it will be sent out to the server.
When I want to finish the websocket, I can send “AT+CIPCLOSE” to the ESP-01 module then the websocket will be closed.
When the server reply, the ESP receive them and send these packets entirely to PIC32MX via Uart, which will store every packet received in a circular buffer.
So I’m in doubt on how to write mbedtls_net_send (and also mbedtls_net_rcv). It is not clear for me on how the TLS will receive a raw packet, encrypt, and send it encrypted using the functions to be implemented.
And as I said, maybe there are some misleading from my part about these things yet.
Note that Mbed TLS does the TLS handshake, and then the encryption. Once the data is encrypted, it sends it through the send callback.
The recv callback will read the encrypted data from the transport layer, and copy it to its output buffer, where the library itself will decrypt it.
In your case, your callbacks should wrap the calls to AT commands. Note: If your modem supports TLS, then it means it can handle the TLS negotiation by itself, and send the data encrypted. However, if you are using Mbed TLS for the TLS negotiation, then you shouldn’t use the TLS feature of thew modem.
Hi @roneld01, thanks.
I was aware of these things.
My doubt still persists. I understood that when mbedTLS wants to send data it will use the send callback. But how is done to actually transmit a packet in the application? How to tell to mbedTLS that I want to send a given raw string? So that the lib will receive that string, encrypt and send using send callback, and do the negotiation before if required.
This is exactly what you need to do in you callbacks
Your recv callback should look like this:
read the encrypted data from the transport layer into the output buffer (using AT commands)
Your send callback should look like this:
write the encrypted data to the transport layer( using AT commands)
The encryption part is already done as in the TLS library. In abstract flow: mbedtls_ssl_write:
get plain data to send as buf parameter
call f_send callback with the encrypted data as buf parameter
callf_recv callback with encrypted data to buf parameter
decreypt data and copy it to the buf parameter of mbedtls_ssl_read
You need to implement the part where you read \ send the encrypted data with AT command and copy to \from the buf parameter
Once you set these callbacks, Mbed TLS will know to use these callbacks within its API, to send\recv the encrypted data
You don’t encrypt and decrypt the data. The library does it for you. This is the purpose of the TLS stack - it handles all the TLS related parts.
All you need to do is to call mbedtls_ssl_write() to send data, and mbedtls_ssl_read() to receive data, as shown in the example
Sorry for my misunderstanding. I was confusing mbedtls_ssl_write with the send callback.
Transmit is ok, now my doubt is about the receiving callback.
Please tell me if the following is correct:
Every byte the MCU receives from the wifi module is put in a buffer that I will call here as buf_a (receives individual bytes via Uart interrupts). Supposing the MCU has received 130 bytes of response, then buf_a is holding 130 bytes at this point. Then, the next time mbedtls_net_recv be called, inside this function I will write 130 bytes from buf_a to ‘buf’ inside mbedtls_net_recv. Write no more than ‘len’ bytes to this buffer, and finally return the number of bytes that were written to buf. Can be like this?
I was checking ssl_client1.c example, where is shown steps 4. Handshake and 5. Verify the server certificate. I have not implemented these steps in my code.