AES encryption demo and secure TCPClient usage

Hi

Does this example apply to the Spark (sorry Particle!) Photon as well? Is the firmware the same for both?

Thanks

The AES encryption routines are part of the system firmware, but they are not (yet) available to application firmware on the Photon. You could copy the source code into your application project files and then the example will work as is.

Thanks for the quick response!

Right so because the system firmware and application firmware are now separate in the Photon some of the routines/functions inside the system code are not available to the applications?

That’s correct. If you could let me know which functions you need I can put them in our backlog to be included in the next release.

Hi,

You mean code communication library?

Hopefully this helps identify a few functions. This code compiles perfectly for the Core, but gives these errors when compiling for Photon.

bleh.cpp:35:1: error: 'aes_context' does not name a type
bleh.cpp:214:18: error: 'aes' was not declared in this scope
bleh.cpp:214:31: error: 'aes_setkey_enc' was not declared in this scope
bleh.cpp:215:22: error: 'AES_ENCRYPT' was not declared in this scope
bleh.cpp:215:61: error: 'aes_crypt_cbc' was not declared in this scope
bleh.cpp:221:18: error: 'aes' was not declared in this scope
bleh.cpp:221:31: error: 'aes_setkey_dec' was not declared in this scope
bleh.cpp:222:22: error: 'AES_DECRYPT' was not declared in this scope
bleh.cpp:222:61: error: 'aes_crypt_cbc' was not declared in this scope

The line numbers and positions will be specific to me, but the error text should help.

Temporary solution:

NOTE: You still have to add the following items to the top of your INO code:

#include "application.h"
#include "spark_protocol.h"
#include "tropicssl/rsa.h"
#include "tropicssl/aes.h"

I am interested in gaining access to all of the hashing functionality that I see used in the cloud communication protocol source code in the firmware tree. Examples of what I’m thinking about are sha1, sha2, md5, etc. I’d also be interested in getting access to the AES functionality as well. I think this needs to be a priority because otherwise it’s encouraging insecure embedded application design or making it a major hassle to utilize.

I would be curious in general for an overview of how to include useful things that I run across in the general firmware, such as these AES functions, in my own source code. I work completely locally and do not use the cloud compile or IDE system as I’m trying to develop a product and integrate with a CI build system, etc. I want to be able to do this with the knowledge that I’m not compiling things twice (once in the main system part binaries and then again in my application binary).

Communication with the Particle cloud is always encrypted. If you set up a webhook from there to call an HTTPS site, as an example, that is of course encrypted.

So, you don’t need to handle the encryption yourself to have secure data movement.

I need it because when the app I’m using was written, we didn’t understand this.

When I compile my app with the aes.h above and the includes listed above, it flashes to a Photon just fine but doesn’t run (SOS 1.). When I compile and run on the Core, it hard resets the instant I try to make an HTTP call (I’m encrypting the payload.)

So, time for me to use a more supported solution, methinks. Don’t make the mistake I did and try to handle encryption yourself unless you know C a lot better than I do.

This is a good suggestion @jhodapp! I’ve added an issue in our internal tracker to be sure it doesn’t get forgotten!

EDIT:
On the Core, the library is available - you just need to include the relevant header files (see a few posts up.) On the photon, you do the same, plus also copy the source and header files to your application folder.

1 Like

@mdma: thanks for the reply. So basically, at the moment, there is no way to not duplicate this functionality across all of the binary sections that get written to the flash part. Thanks for adding it to your backlog.

@mdma Does the web IDE build a separate application binary that gets flashed to the photon? When @jhodapp and I tried to include the AES encryption header file and use its functions from the web IDE it compiled and flashed just fine. Does that mean the web IDE automatically duplicates the source files or does it behave differently than building from command line and generates one binary that includes the app-level and the firmware?

Are you using a Core or a Photon?

Sorry @mdma, for some reason I didn’t get a notification email that there was a response. (I used to get them before this post).

We’re using a Photon.

Thanks for confirmation. If you’re using a photon, I’m puzzled how you were able to successfully compile or flash AES unless you’re including the sources directly in your app. At present, that’s the way to get AES support on the Photon.

Sorry, I guess at some point I did not have a Photon selected and so the code that included the AES calls verified correctly (since it was compiled for the Core). Now when I select a Photon to flash and then “Verify” I am getting the same compile errors as in the command line.

So, I guess the bottom line is that we would have to duplicate the files in order to use the AES functions.

2 Likes

I thought I might add how I did this for the command line/off-line compilation. I’m using version v0.6.0-rc.2 of the firmware code and compiling in mbedtls. Please let me know if I’m missing a step as it required some tweaks to the setup and I can’t be sure I included them all here.

NOTE: $(PARTICLECODE) is your git directory of source code.

  • In my application’s directory, I soft linked to the following files and dirs (not sure if spark_protocol is required):
communication/lib/mbedtls/include/mbedtls
communication/src/spark_protocol.h
communication/src/spark_protocol.cpp
/usr/local/Cellar/gcc-arm-none-eabi/20150925/arm-none-eabi/lib/armv7-m/librdimon_nano.a
  • We need to add some compiler directives to make this work. In order to modify the build process, we need to modify the $(PARTICLECODE)/firmware/user/makefile, by adding this line to the top: (NOTE: This is a handy hack for ANYONE that is working on command line as you can change the compile process)
#include ./applications/$(APP)/include.mk
  • Now, create the include.mk file in my application directory. This allows me to tweak compile settings like adding libraries or changing compiler options.
CFLAGS += -I$(PARTICLEHOME)/communication/lib -DUSEAES

ifdef APP
LIBS += rdimon_nano
endif
  • You’ll notice I added the rdimon_nano library. That is for additional code mbedtls needs. However, it conflicts with code (_kill and _exit) in modules/photon/user-part/src/newlib_stubs.cpp. So, that compiler define will come in handy. Edit newlib_stubs.cpp and add this around the _kill and _exit functions:
#ifndef USEAES
<function>
#endif
  • you may need to recompile the Particle library now (can’t remember). But, those defines mean any projects that don’t have a -DUSEAES, will have the Particle _kill and _exit, but your project will grab them from librdimon_nano.

  • Now, go to $(PARTICLEHOME)/firmware/main and make APP=$(APP) all. Let me know if there are issues.

2 Likes