Hello, lately I have been trying to translate the Vivokey chipscanlib into an Arduino sketch. The chipscanlib has a lot to unpack, so currently I have only worked towards Spark 2 capabilities (my implant of choice.) AT THIS TIME THE SKETCH DOES NOT WORK. But I believe it is very close… The sketch is dependent on the ArduinoJson Library and the Seeed-Studio PN532 Library. I’m not a professional coder and I don’t know how to use Github, so please take this collection of code snippets that I haphazardly threw together with a grain of salt. I tried my best to comment everything.
NOTES:
Written for ESP32-DEVKIT V1.
Uses the Touchpad-Wakeup to boot up when a specific capacitive pin is touched to save energy.
Success is marked by pin 22 turning on then off, and the onboard led flashing.
IMPORTANT:
The default SPI clock speed of the ESP32 is too high for the PN532. The SPI clock speed is set by the PN532 library to 1/8th the CPU clock speed, this means by default the SPI clock speed will be 30MHz. The problem with this is, the PN532 has a maximum SPI clock speed of 5MHz. To fix this, we can either slow the CPU by using the Arduino IDE, or we can edit the PN532 Library to set a larger divider. Since lowering the CPU speed enough will disable WIFI/BLE communication, a larger divider is the only option. To do this, open PN532_SPI.cpp and change:
_spi->setClockDivider(SPI_CLOCK_DIV8);
To:
_spi->setClockDivider(SPI_CLOCK_DIV64);
Now when the CPU clock speed is 240MHz, the SPI clock speed will be 3.75MHz. Perfect for a PN532.
Honestly, I don’t know alot about it, so I’m going to post this gif to “bump” the topic so there can be a higher chance that a knowledgeable person with spare time can answer you.
It’s not typical basic NDEF. You don’t just read/write data. The Spark does way more.
The spark reports back a url, but that’s not the interesting part, that is the cryptography it can do, which VivoKey APIs use to prove it’s really this specific implant that is talking with VK.
You have to tell the spark what to do, you need to send and understand APDUs so it can solve the challenges the VK api requires.
If my understanding is correct any Wifi-enabled 13.56MHz NFC reader can use the Spark 2’s cryptography. So, smart phones with NFC capabilities would be the closest thing to a “matched reader” for the Spark 2.
Sadly smartphones start to get expensive when you want to place a few Spark 2 mutual authenticators around the house. Which is why I’m attempting to make this reader.
We may explore, at one point down the road, the ability to register a public key with our API such that we can then export a private aes key for spark and spark 2. These chips have 3 user keys programmed. We use one key for API, one key will be used for physical access control type hardware from VivoKey, but the 3rd we’ve always contemplated letting users export that key and use for their own offline chip scan validation directly.
I would appreciate having the opportunity to personally compromise one of my three keys. Especially if it means offline chip scan validation for the Spark 2.
We will see about it. The key permissions are such that the key cannot be changed… like, there is no way for us to allow key 2 to change itself and not totally open the rest of the chip to bad things, so once the key is exported to the VivoKey member, it’s out “in the wild”.
This would save me alot of time and headaches right about now… Are these products coming soon™?
I’m still working on my rendition of a Vivokey xac but I seem to be missing information about a crucial step between receiving a challenge from the get-challenge endpoint, and posting to the pcd-challenge endpoint. Help from anyone would be appreciated.
possibly… though the solutions we are looking at involve retrofitting overtop of existing lock hardware… so more of a lock manipulator instead of a lock. The reason for this is that many people rent and are not allowed to change the locks… but usually there is nothing in any lease agreements about adding lock manipulation hardware to actuate existing locking mechanisms themselves.
