[Question] Encryption's documentation

[Sami32]

AES-128 CTR?
Please, feel free to correct me.

If i remember correctly?, Inputstick use AES-128 CBC (BLE) and Evikeyboard use AES-256 CBC (NFC) encryption.

[larrylart]

It uses BLE transport encryption (AES-CCM 128-bit) + custom application-layer “micro-TLS” (payload encryption) - PBKDF2-HMAC-SHA256.
Micro-TLS is to protect from threats that BLE encryption does not fully cover, ie malicious local apps - like another app on the phone accessing BLE.
I had little free time lately and used most to fix some bugs in connectivity and work to create additional client apps for linux and iphone, but I will put up some basic docs on implementation.

[Sami32]

Thank you very much for your great work +1

[larrylart]

Thank you! I originally started this as a small weekend project to solve a personal need. At the time, I didn’t know products like InputStick already existed ... if I had, I probably would have gone with an off-the-shelf solution. That said, I’m now glad I didn’t, because I strongly believe a product like this should be open source, given the security and sensitivity involved.

The first implementation was very basic, relying mainly on BLE with AES-128. Since then, I’ve added mTLS, moved to a more efficient binary protocol, and made several architectural improvements. I’m currently cleaning things up and fixing connectivity and provisioning issues. A new release in the next few days will address many of these, and I’ll likely iterate a few more times until the flow is lean and 100% reliable - well, as much as the many varioations of BLE stack for various devices can handle.

I’ve also built simple, bare-bones clients for the main platforms - Android, iOS, and Linux. While I could add more features (like macros or mouse support - I had a look the other day at the InputStick app), I’m being conservative for now (give little free time I have nowadays) until people express their interest for this. My main focus for now is getting a stable and efficient core functionality first.

[Sami32]

I totally agree and have already an InputStick key but i've ordered a Lilygo T-Dongle S3 with LCD to test your work, so i'll probably receive it before the end of this year.

Your project is still under the radar but when the people will know about i'm sure that they will like very much ;-)

[larrylart]

i've ordered a Lilygo T-Dongle S3 with LCD to test your work, so i'll probably receive it before the end of this year.

That’s great! Because right now, besides me, it’s just a friend of mine helping with testing.

By the way, I’ve managed to release most of the code and builds I’ve been working on over the past 2–3 weeks, except for the iOS code, which still needs some review for a few edge cases. I’ve also moved the Android app (BluKeyborg) to its own repository:
https://github.com/larrylart/blukeyborg-android

Also, something that may interest you is the new approach for integrating with KeePassDX — I created a new fork here:
https://github.com/larrylart/KeePassDX

Instead of my old brute-force integration of the entire Blue Keyboard stack (which had a large surface area), I’m now using an AIDL client–service interface. This keeps the integration minimal and also allows other HID providers to integrate their apps with KeePassDX much more easily.

This approach does require having the BluKeyborg app installed, since the app now handles communication with the dongle.

As a proof of concept, I also modified the InputStick KP2A plugin so it can receive passwords from the KeePassDX AIDL fork. Unfortunately, I don’t have an InputStick myself to test end-to-end — I can only confirm that it receives the message, not whether it actually types it. If you’d like to test it and have the time, you can find the release here (in contains all the files required, includeing the apk for the modified InputStick KP2A plugin):
https://github.com/larrylart/KeePassDX/releases

I ended up with a lot of repositories out of this, I am just gonna list them here so you, and I, can keep track:

• https://github.com/larrylart/blue_keyboard - main dongle firmware and some integrations samples for clients
• https://github.com/larrylart/blukeyborg-android - BluKeyborg - android companion app and driver for the dongle
• https://github.com/larrylart/blukeyborg-ios - BluKeyborg - iOS companion app and driver for the dongle (pending first release)
• https://github.com/larrylart/KeePassDX - fork for new integration experiment with AIDL
• https://github.com/larrylart/KeePassDX-kb - my original modified clone, might phase this out if the AIDL is the chosen one..
• https://github.com/larrylart/KP2APlugin - fork for new integration experiment with KeePassDX/AIDL

[larrylart]

i've ordered a Lilygo T-Dongle S3 with LCD to test

Did you received the dongle? Curios how it works for you. Btw, I released a new firmware version and android app, that should make setup easier, see Releases.

[Sami32]

Yes, finally, i received it yesterday...after that i complained recently to my postal service for having it locked in the tracking application since the 26 december :-(

Thanks to the russian hackers...

I will try to test it this week-end ;-)

[larrylart]

Meanwhile I have made a few changes to the android app to make it more predictable in the initial setup, I separated the dongles display and provisioning from setting.
I also tested and created firmware for several other esp32s3 boards, and a generic dark/no screen, no led what should work with most esp32s3 hardware - https://github.com/larrylart/blue_keyboard/blob/main/HARDWARE_SUPPORTED.md

Just a note, the keyboard layout (FR) might not work properly in for certain characters since I focused mainly on the coms and a reasonable stable core so far. However I have split the keyboard layouts in separate files - to make the mapping corrections easier - https://github.com/larrylart/blue_keyboard/blob/main/blue_keyboard/kb_layouts/kb_layout_FR_WINLIN.h

[Sami32]

After having solved a Windows network config blocking my access to 192.168.4.1 i finally configured my LCD and NoLCD dongle keys but no device was discovered with BluKeyborg v2.0 on Android 7.0.

Any idea? (Blue Keyboard Firmware v2.1.0)

[larrylart]

Do you have the LilyGO t-dongle with display? for that this should be the firmware - bluekb_firmware_v2.1.1_esp32s3_lilygo_tdognle.bin

Also in the app make sure you tap on the bottom right icon (devices). I really need to make that more obvious. The dongle should be there if not close the app unplug/plug the dongle and open the app in that screen again.

[larrylart]

Also older Android ie 7.0 have issues with BLE. Currently the app/dongle uses an MTU of 185 that seems to work best with most newer phones 2020+. I think I have an older phone around I will give it a try and see it works.

[Sami32]

Yes, LilyGO S3 T-Dongle with TFT display and one without...so it seem that BluKeyborg doesn't work with Android 7.0 yet? (InputStick App support it)

I'll try with Android 10, and with a Debian flavor later.

[larrylart]

Will have a look once I get my old phone charged. Android 7 had a poor implementation for BLE stack, it might be the case that the BLE MTU I am pushing (185) is too much for it. I will try to use MTU 23 if that is the case, and if that works I might add an option in the wifi setup to set the MTU for the old phones.

[larrylart]

I think I might have fixed the problem on android 7. try this version from here: https://github.com/larrylart/blue_keyboard/tree/main/tmp/

I only tested this on android 8, so far, the android 7 phone is installing for 10 minutes ...
On 8 it took a few tries in setup until it finally showed the pairing popup.

[larrylart]

If BluKeyborg_v2.0.0_andro7_8.apk does not work on 7 try BluKeyborg_v2.0.0_andro7_mtu23.apk
For me this can see the dongle and pair but provisioning fails, but this could be my old phone that seems to be acting.