HomeKit update, non-commercial version - SRP

Hi, there was a previous post about this three years ago (here) but now HomeKit for iOS11 has a non-commercial license which you can learn about here: http://developer.apple.com/homekit

The spec details WiFi based pairing protocol using a modified Secure Remote Password public/private key generation. I’d like to work on developing this for my Photon board. Any interest in collaboration?



Hi, a brief update. This should be possible to achieve with the WolfSSL / WolfCrypt open source library which has an Android build. You can find some relevant libraries below & I’ll update my progress on this thread. Basic HomeKit API will eventually follow this pattern:

void setup() {

Bonjour.setUDP( &udp );

Homekit homekit = Homekit( lightbulbType );
Characterist *light = homekit.newCharacteristic( onSetting );


void loop() {


TCPClient client = server.available();
if (client) {
    homekit.process(  client );

    uint8_t onOff = light->intValue;
    Serial.println("Lightbulb is ", onOff );

    if ( onOff ) {
          digitalWrite(LED, HIGH); // sets the LED on
    else {
          digitalWrite(LED, LOW);  // sets the LED off



HomeKit support will depend on a series of libraries, including a high-level HomeKit controller, UDP based Bonjour networking client, TCP based HTTP parser with Apple specific TLV8 codec, SRP based handshake protocol with Apple specific crypto (all supported within the WolfSSL Crypto library). The low-level Bonjour and TLV8 libraries have been tested on a Photon device. Currently trying to port the WolfSSL library to a Photon.

Main Particle Library:

Particle EthernetBonjour Library:

Particle TLV8 Encoding Library:

WolfSSL Testing:

Original WolfSSL Library:


Are you aware of this thread?


We could use a tester or two. If it works ok enough I can publish it on the web IDE.

1 Like

Thank you for the reference, @Moors7. I’m looking at @cermak’s library now.

1 Like

Hi @cermak and thanks for the work on the WolfSSL Crypto port. I’ll be sure to help test your library, but the Apple HomeKit spec uses a specific subset that I think needs to be configured and tested separately; both for accuracy and of course potential storage savings. Specifically, I will test:

  • srp with N=3072 g=5
  • sha512
  • chacha20_poly1305
  • ed25519


1 Like

So, SHA512 is disabled. Just comment out the define and it will be re-enabled. I am not sure about the other protocols.

1 Like

Nice, and thanks for the detailed PORTING.md document. Very helpful. I created a pull request to add a simple SRP test. It compiles but I haven’t yet tested on the photon board.

1 Like

I’d love to help out, will endeavor to look through it all later tonight

1 Like

Anyone got a working example?
I have built a few dimmers, a garage door opener and a thermostat. Have them all added to HomeKit using Home bridge, but would love to test to build native HomeKit devices :slight_smile:

1 Like

Great idea! Thanks for trying to port Homekit DNA to Particle world!!!
I am certainly interested in testing a version which is usable with my limited level of C/C++ experience.

Following your progress till that happy day arrives!

Hi, this project has stalled although I did reach out to Apple engineers to seek their support. Development will require knowledge of iOS / MacOS and currently uses Swift, ObjectiveC, C & C++ for testing. In short, it’s a lot of work.

The issue is that the Apple spec is incomplete regarding crypto protocols (eg. ChaChaPoly) specifically regarding corner cases of zero padding. Thus, a software emulator was created as a test bed which uses the WolfSSL library so that a port to Particle ARM will be possible.

You can find the latest emulator based code online, here:


1 Like


I am interested in your HomeKit integration for particle. I found this one for ESP8266 https://github.com/HomeACcessoryKid/ESP8266-HomeKit
They are using WolfSSL indeed, maybe you can have a look at the source code and solve your problem?


1 Like

Thank you, @Mick1

That’s a good reference for a WolfSSL based HomeKit implementation. I’ll take a look at it !

1 Like


Thanks for the effort on the homekit-particle git repository (https://github.com/moflo/homekit-particle).

I tried compiling your example (usage.ino) on a photon with 0.6.3, (or 0.6.0) but I do get the recurring errors:

sha.h:158:5: error: unknown type name ‘uint64_t’ uint64_t state[8];
And other same type of error for uint64_t or uint8_t.

Do you know what I’m missing? I tried including manually at the top of the usage.ino the particle.h and application.h but it does not solve that particular problem.

Thanks in advance for your help,


1 Like

To all who contribute to this subject: Thanks for your efforts!
I am surprised about the lack of interest from Particle engineers to contribute…

On the other hand, I notice few responses from forum members:

Is anybody else interested in a simple integration op Particle devices with Siri / Apple Homekit?


While I’m interested in homekit integration as well, I can understand why it isn’t a high priority for Particle. Apple is pretty notorious for strict certification rules and whatnot, and making sure everything is up to their standard (and keeping it that way) would put a disproportionate strain on the development of the ecosystem as a whole. Seeing as there aren’t hundreds of people actively rooting for this (in a developer community of tens of thousands), it would seem interest isn’t that great at this point. Should that change, I’m sure Particle would take this into consideration.
Until such time, and another reason for not investing a lot of time in making it supported natively, is that the workaround is surprisingly simple and cheap. For less than $10 you’ve got yourself a rpi0W that can handle multiple devices, and can be set up by relative novices. Doing it this way, you take the additional burden away from your resource constrained devices, and place the ‘load’ on a dedicated pi, which can handle multiple devices. In the trend of ‘distributed computing’ of whatever you want to call it, this seems like the preferred option.

If not for commercial applications, is there a reason why a Pi homebridge setup wouldn’t work where a native implementation would?


Very useful comments @Moors7, thanks!
I will definitely try the Homebridge way when I find the time for that.
But especially now with the introduction of the “meshing generation”, I wonder how a mixed network of 2nd and 3rd generation Particles will integrate with Homebridge.

In other words: will it be easy to control “particle.functions” on all devices with Siri on such a constellation?

Could somebody shed some light on this?


Homebridge was my first real usable project on a Pi, and it’s been running almost flawlessly for over a year with my Particle devices (amongst others). Seeing as it can be used with other products, who would otherwise not have homekit integration either, I’d almost prefer it over the native solution. And it really isn’t too hard to setup either, as long as you follow the simple guide. That said, if someone develops a working library, I’m all for it as well.

As far as the gen3 devices are concerned, controlling them should be as easy as the current hardware. You can use argon directly to wifi as you would with a current photon, or you can choose to use a meshed xenon end-node, whose messages get routed through some of the mesh nodes.
I think the idea is that you should still be able to call the Particle functions, regardless of the network topology you chose to use.


OK, that’s a very interesting explanation, thanks!
Must try it out…
Indeed, the cost of a PI is neglectible these days.