Re: QR Code data transfer protocol?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Robert is right, manufacturer compromise is a real issue and it is not always intentional on the part of the manufacturer.

I have seen USB keys that were compromised incidentally by a testing device that was infected by a random malware attack. In other cases an employee has bee compromised. In others, the manufacturer is hacked.

'Zero Trust' is a terrible name for what we used to call 'least privilege'. Zero is unobtainable and often counterproductive. Separation of duties between two low-trust parties is better in practice than zero trust in one and absolute trust in the other that is ignored because they are outside the security envelope.

What I do with threshold is the following:

* Device has private key and credential installed during manufacture which will be relied on for the sole purpose of authenticating the device during onboarding. 

* Breach of the manufacturer installed device key has minimal impact on the security of the device because onboarding is performed once and any attacker would have to maintain an active attack on the channel.

* The device credential is self signed.

So I do anticipate the use of device certs. But they really don't need to be tied into anything special unless we have a requirement for the device to authenticate itself to a party that isn't the owner. Which is a requirement for certain DRM or compliance certification situations (e.g. CableLabs).




On Tue, Jul 18, 2023 at 5:48 AM Robert Moskowitz <rgm-ietf@xxxxxxxxxxxxxxx> wrote:


On 7/17/23 22:45, Raghu Saxena wrote:
>
> On 7/18/23 01:27, Robert Moskowitz wrote:
>>
>> 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.
>>
> What about the offline system accepting the CSR via a flash drive, or
> other device to bridge the airgap? Is the argument you don't trust the
> party providing the CSR? Or if it is some kind of MiTM, and an
> adversary actually changes the QR code you're seeing on your side
> (e.g. someone inside Zoom who can control the video feed). You would
> end up signing the wrong cert.

This is for:

https://datatracker.ietf.org/doc/draft-moskowitz-drip-dki/

And yes, I suspect USB devices.  Have since I found something hidden in
one that I got on ebay (this WAS lots of years ago) that I was removing
everything to make it a Linux device.  There was a hidden partition
there that did not belong had some interesting looking code. (you DO get
what you pay for)

Now I am paranoid.  I get a new USB device for use on a Win system, I
check them on Linux first...

But really, the USS model does open up the potential for lots of CAs
that are not so little (millions of UA mission certs each).  Do I want a
design that trusts them all to do the right thing?  Also, with USB they
either have to travel to where the signing CA lives or ship the USB
stick.  A zoom conference to perform the signing operation is more cost
effective.

So, no, no USB in the design.

It is not JUST paranoia.


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux