search

httpslocal / proposals

Concrete proposals on HTTPS for local servers
11 stars 3 forks source link

[META] Initial step to trust a device #3

Open tomoyukilabs opened 5 years ago

tomoyukilabs commented 5 years ago

This is a meta issue to discuss how to trust a device at the first time. Unless we could rely on existing Web PKI, such an initial step would be required to determine whether the device would be the one that the user would really wish to connect. Possible approaches are:

Any additional suggestions or detailed comments for proposals are welcome!

X-Ryl669 commented 5 years ago

Proposal 3: Let's say you have PKI accepted, then the browser will display the device's (first part of the number tag sticked to the device, serial number, model) extracted from the self signed certificate. The user can check if it's the right device and be asked to input the last part of the number tag to pin the certificate. This information can not be known by a MITM. The security in that case is based on a secret information that's only known to the user.

Proposal 4: There's also the WIFI's WPS like first authentication. Upon first connection, the browser submit a time limited challenge on the device (or the opposite). The user will have to press a button on the device to validate the challenge. If the challenge is validated, the browser pin the certificate/key. The security in that case will be based on physical presence of the user in a limited time frame. A MITM must simulate the device during that time, and that's supposed good enough for WPS key exchange. This requires a button on the device however.

Proposal 5: Using a remote validation. Let's say you have an internet host with a valid domain certificate (likely, the manufacturer). Let's say the device's fingerprint is signed by the remote host certificate. The browser, upon first connection to the device will:

  1. Download the device self signed certificate (optionnaly containing serial number & model & manufacturer)
  2. Extract the device unique fingerprint
  3. Extract alternative validation server
  4. Download alternative validation server's certificate and find its public key
  5. Ensure the signature of the device's fingerprint by the validation server is good
  6. Display a friendly message to the user to connect to the (certified) device
daniel-kun commented 5 years ago

@X-Ryl669 Regarding 5.: I'm not sure I understand this correctly. We need a mechanism here that guarantees that the trusted online domain and the yet untrusted device prove that they trust each other, e.g. by sharing a secret. From what I understand, your workflow only guarantees that the device provides publicly accessible parts of the certificates, which I think can be faked and re-used, or maybe I got it wrong.

X-Ryl669 commented 5 years ago

The device fingerprint is signed by both the device private key and remote trusted domain's private key. No MITM can do that (they don't have the keys) nor can they reuse the certificate since the private key is required to generate the session's secret key (as usual in TLS).

It's a bit like if the trusted online domain would act as CA, but without all the trouble.

daniel-kun commented 5 years ago

I see! Sounds good to me (I'm not an expert on this matter!)

tomoyukilabs commented 5 years ago

@X-Ryl669 Great! Thanks for your suggestions.

Proposal 3: Checking Device Identifier in Certificate

It seems a similar approach to 1., but it provides more detailed device information and trust infrastructure. Human-readable information such as model name, manufacturer name, etc. looks more helpful for users.

On the other hand, I'm skeptical about just looking at information displayed on the browser, because most of users tend to just click buttons like 'accept' or 'continue' without checking them carefully. This is one of the reasons why use of passcode authentication like PAKE is often considered.

Anyway, I expect that that I-D can provide us with helpful information. Thanks!

@dajiaji @yoneyajp could you review the I-D draft-friel-pki-for-devices-00 if time permits?

Proposal 4: WPS-like Setup

Eventually, it looks like kind of passcode-based device authentication, right? In this manner, this approach seems close to 2. to me. (details are different, though) Anyway, as you have pointed out, "This requires a button on the device however."

Proposal 5: Remote Validation

Some of members in this CG (W3C HTTPS in Local Network Community Group) have a keen interest in this type of approach. For example, @dajiaji has introduced his strawman proposal to issue a certificate to a devices. (His proposal looks too much detailed regardless of an early stage, though.)

Anyway, that approach looks good to me. Thanks!

@dajiaji @igarashi50 I wish you could put any comment here. Thanks.