There are certainly pros and cons to both. I have been thinking about this a lot, and so I definitely appreciate the discussion points.
The biggest issue I see with storing the keys on the gateway is that is not how the Core does it. If this were to become a product, then keeping the FW in-line with the Core’s would be important. The further they diverge, the harder any merges would be.
The handshake is really the biggest issue I ran in to. I suppose you could move that off the SparkLE and into the gateway, but then the keys would need to be the same on both. So you would have to update the keys on both at the same time, and then they are locked together. Plus, if there was ever a change to the handshake, you would have to merge it with all the gateway code. I imagine a gateway being a smartphone (iOS, Android, or WP8), a Core+BLE Shield, a PC (Windows, Linux, Mac), your car, or anything else that has BLE and an internet connection. So keeping the gateway simple will save a lot of trouble, I think, as there could be many different versions.
I think my ultimate requirement would be to have any particular SparkLE hook to any gateway, without the need for sharing keys. That could also present some security issues though, as people could hijack SparkLE’s if they are in range. So maybe the SparkLE should only work with gateways that you specify, like how the Core works only with specific Wifi routers that you configure. Maybe there could even be a Public option, so that you can connect to any gateway if you want, just like public Wifi routers.
I think the biggest thing I learned, however, is that it is not just the security portions but also the Core FW in general. Some can clearly be cut down, but even with moving the RSA security off, I am still almost out of RAM, there is only 8k. So this chip probably won’t have enough anyway, there would be very little left over for user sketches. I think we need a bigger MCU no matter what.
Anyway, I am rambling at this point, but certainly lots to think about.