Do the devices in question have the ability to communicate via a network in addition?
I have developed a protocol with multiple connection modes using QR codes (or potentially NFC) to provide a direct channel for authenticating the request. These vary according to which device has a QR code presentation capability and which has the reader capability.
So I buy a new coffee maker, it doesn't have a display, just a QR code printed on the underside of the device and a reset button. I unbox the device, scan the QR code, the device now has connection to all 4 of my home WiFi networks and has been provisioned with threshold shares to create a unique set of keys for communicating within my personal Mesh. It is also registered in my maintenance catalog so I can look on my home dashboard and see when it was last descaled, when were consumables last ordered, etc. etc.
If the device is a tablet computer, I flip to the 'device connect' on one of my admin devices and scan the active QR code there.
If I am establishing a connection with another person, we both go to 'QR code connect' both our phones show a QR code and put the camera in scan mode. Only one of us needs to present, the other scans and we both get each other's contact.
As you would expect, there is a full 256 bit conventional /128 bit quantum work factor for the mutual authentication.
In each case the connection established is multi-purpose. Alice and Bob don't just exchange a Mesh messaging credential, they exchange active credentials for all the applications they want to share. So if Alice has a 'personal' credential and a 'developer' credential, the first might have her signal, telephone, home address, etc, the second might have her Signal, git Signing, git SSH, code signing, etc. etc. If she adds or changes part of a contact, it updates automatically on a best effort basis. The Mesh credential exchange is used to authenticate the rest.
If it is a device that is added, my approach is that the manufacturer installs keys at manufacture, they are permanent to the life of the machine and they are *only* relied on to authenticate in the onboarding process. During onboarding, an entirely new set of keys is established using a threshold technique to guard against incompetent/malicious manufacturer weak keys. This set is fixed for the duration that the device is connected to the user's Mesh. It is not exported from the device under any circumstance and is ideally bound to that device hardware so that extraction is difficult or impossible.
Got running code and demos in console mode. I was hoping to be able to demo the GUI version in SF but had other issues. The prototype runs on Windows, macOS, iOS and Android.
On Mon, Jul 17, 2023 at 1:28 PM Robert Moskowitz <rgm-ietf@xxxxxxxxxxxxxxx> wrote:
On 7/17/23 13:17, Michael Richardson wrote:
> Robert Moskowitz <rgm-ietf@xxxxxxxxxxxxxxx> wrote:
> > Is there an existing protocol to transfer a data file via QR codes?
>
> > Say one computer shows a QR code on it screen and the second "reads"
> > it.
>
> My impression is that TIGRESS aims to include QRcode as a way to initiate the
> credential transfer. Other transports would be various kinds of (instant) messaging.
>
> > The application is for a disconnected system to "safely" receive a data
> > file to inspect and use and have a high degree of confidence that
> > nothing else is sneaking through.
>
> TIGRESS does not really allow the receiver to be *offline*, but not connected
> directly to the sender. If your content is small enough, I imagine one could
> use data:// URL within the QR code itself.
>
> > I want this for transfering a PKIX CSR to an offline signing CA that
> > would then respond with the cert (or a NAK to the CSR).
>
> All over QRcode?
> And is if offline that you really want, or just assurance of physical proximity?
Offline.
Consider a CA signing process where one party is in the US, the other
Canada. They are meeting over Zoom.
The requesting party holds up a computer with the CSR data in a QR
code. The ones I am making should fit.
The signing party holds up their offline signing system to receive the
QR code and create the cert which it then encodes in a QR code.
The signing system then displays the cert QR code to be read from it.
Thus the system with the signing private key is never connected. The QR
content is read to be processed but should never be tried to see if it
is code to corrupt the signing system.
Not for frequent use. But rather for signing with root keys or
intermediate keys for issuing certs.
A potential way to move to not-in-person signing.
Can I get an auditor to agree this is OK? well with the cost of travel
and such, I need such an approach...
Bob
