Exotic SQRL hardware clients - brainstorming

[HazelnutThief]

Hi people!

Given the frequently less-than-optimal security of many endpoint devices (desktop/laptop here, mobile there), i wonder if one can build dedicated peripheral hardware clients without any network connectivity (which stores the secret and computes the crypto) and maybe with unusual communication protocols between the host and peripheral.

Can we come up with good hardware ideas and discuss the pros and cons of each?

I'll start with a QR reader + display:
How it works:
1. peripheral scans QR code with SQRL URL (sqrl://example.com/sqrl?nut=...) [challenge]
2. peripheral displays domain and prompts user to select identity
3. user unlocks identity and confirms login
4. peripheral displays QR code with SQRL response
4.1 variant 1: direct URL for SQRL login (https://example.com/sqrl?client=…&server=…&ids=…) encoded as URL parameters
⇒ user scans QR code on host device (URL is unmodified)
4.2 variant 2: compressed POST parameters
⇒ SQRL app on host device decompresses the data, then sends POST request
5. host issues HTTP request containing SQRL response (GET or POST), user is authenticated

Inspiration:
* German online banking authentication scheme (ChipTAN+ with FlickerCode)

Pros:
* mostly compatible with SQRL specification
* variant 1: no software client required on host
* offline peripheral

Cons:
* host needs camera
* camera in peripheral is expensive
* image processing (QR decoding) costs time and energy (limited on peripheral)
* variant 1: GET request not entirely compliant to SQRL spec (afaik, please correct me if i'm wrong)

Cheers!

 

[HazelnutThief]

One could also communicate the challenge/response not via QR codes between host and peripheral,
but via lower-level hardware links:

Pros for all:
* no need for a camera on the peripheral device
* no CPU cost for QR decoding

USB:
Pros:
* widely available host interface
Cons:
* yet another type of USB device
* device drivers
* permissions for userspace applications

Other serial data link (RS232, RS485, SPI, I2C, 1W):
Pros:
* simpler than USB, Bluetooth
Cons:
* host interface not widely available
* slower

Voiceband audio (like ancient modem/acoustic coupler):
Pros:
* widely available host interface (mic + speaker)
* obvious communication
Cons:
* noisy
* slow
* host requires access to audio input/output

Low ultrasound audio (like ancient modem/acoustic coupler, but between 16 KHz and 20 KHz):
Pros:
* widely available host interface (mic + speaker)
Cons:
* slow
* host requires access to audio input/output

Infrared:
Pros:
* photodiodes cheaper than camera
* decoding cheaper (in terms of peripheral cpu)
Cons:
* host interface not widely available

Bluetooth/NFC:
Pros:
* wireless
* most devices have
Cons:
* eavesdropping
* browser requires access to Bluetooth/NFC interface
* persistent detection of peripheral or host device

Modulated light, Flickercode-like, either parallel or serial:
Pros:
* widely available interface (from host to peripheral)
* visible and obvious
Cons:
* maybe harmful for epileptics
* slow

And one could also use two different channels,
for example Flickercode from host to peripheral
and QR code from peripheral to host.

 

[PHolder]

I don't want to be mean... you have some great ideas, but: There is no one using SQRL, so really what needs to be focused on first, before novel hardware clients, is adoption of SQRL by anyone with a reasonable user base. I assume, as I have mentioned elsewhere, that adoption is being held back by a lack of an official document in the "Internet format"... i.e. an RFC.

If we could get a good use case, maybe we could get someone to build a SQRL client directly into a browser (like Firefox), that would use some of the WebAuthn tech to communicate to a hardware device. You could easily build a little crypto device out of something like a Raspberry Pico and a cheap touch screen display (for the user to see the site URL and authorize the access.)