search

w3c / wot-security

a repo exclusively for security to better manage issues and security considerations for WoT
https://w3c.github.io/wot-security/
18 stars 22 forks source link

Add integrity protection (proof section) to TDs #166

Open mmccool opened 4 years ago

mmccool commented 4 years ago

A "proof" section, like in DIDs, should be added to TDs to protect their integrity. This is important if we want to do things like refer to public keys, etc. from inside TDs; we don't want a man-in-the-middle to spoof that information.

mmccool commented 4 years ago

See also https://w3c-ccg.github.io/ld-proofs/, which are designed for JSON-LD files, and are what DID document integrity proofs are based on.

mmccool commented 4 years ago

I think we agree we should adopt a common standard for signing json-ld documents. However, we should review the proposed json-ld signing spec above (ld-proofs) to ensure it has the "right stuff".

mmccool commented 4 years ago

As noted in the proposed new section 7.4 in the security guidelines document, there are alternatives like JWS that might be considered for "external" signing. These might make sense in the content of a directory service (that might return a TD that does not have "intrinsic" signatures like in ld-proofs). This might also apply when a directory returns part of TD, e.g. the result of a query.

mmccool commented 4 years ago

I will work on a PR for this... using ld-proofs... will see if I can do it in time for the TD 1.1 FPWD, if it's optional then it can be backward-compatible.

mmccool commented 4 years ago

Created an issue in the TD repo where it belongs... will follow up there. Already given the TD group a heads-up also. https://github.com/w3c/wot-thing-description/issues/940

mmccool commented 3 years ago

PR Available, but WIP, need to resolve relationship to DID ontology, etc. Should consider what steps we need to complete this (for TD 2.0), and also a testing/implementation plan.

mmccool commented 3 years ago

So this PR is now obsolete and will have to be redone, and of course we'll have to deal with canonicalization.

mmccool commented 3 years ago

Discussed in APA call the need for "progressive disclosure" in many circumstances. This is related to the general idea of returning different variants of TDs to different users. This shows up in at least the following use cases:

So the question is... how do we handle signing in this case? Is "proof chaining" sufficient? This does imply that a "master" exists which contains the "original". The above processes can add, delete, or modify information. But in general I won't know what was changed, so in addition to knowing that there was a change, should I have a general mechanism to get access to the original or a diff? Defeats the purpose in some use cases (e.g. hiding information).

mmccool commented 3 years ago

Requirements arising from memory limitations:

The above generally means that profiles will probably have the requirements that TDs and TD templates are stored and transmitted in canonical form, and should be pre-validated.

See https://github.com/w3c/wot-testing/blob/main/events/2021.03.Online/reference/hw.md for a discussion of minimum hardware requirements. One note that is relevant: security requirements should be aligned with hardware acceleration availability.

Use case for consuming TDs on constrained devices needed. One example:

Notes:

Canonicalization requirements:

mmccool commented 3 years ago

TODO:

mmccool commented 3 years ago

Need to update proposal. Consistency with available HW acceleration for signing capabilities would be useful (see PR https://github.com/w3c/wot-security/pull/199); in addition, we have to decide how to populate the namespace for various signing algorithms. The following might be useful for that: https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-18 In addition, we do have some existing names defined, e.g. for tokens, and it would probably also be useful to be consistent with names used by protocols, e.g. HTTP and CoAP. The "alg" examples for token are consistent with jws/jwt/jwe, and it makes sense (since a TD is a JSON object) for signing to use jwe, etc. We can start with LD-PROOFS (https://w3c-ccg.github.io/ld-proofs/#linked-data-signatures) but don't need to be constrained by it.

mmccool commented 3 years ago

Signing should also require:

  1. Canonicalization. Signing a TD is also asserting that it has been canonicalized.
  2. Validation. Signing a TD is also asserting that it has been validated.
mmccool commented 3 years ago

Signature type? If we could have only one, what should it be? @Citrullin I suggest SHA256 (cryptographic hash) combined with ECDSA signatures (note: elliptic curve, so compute required, regardless SW implementation is ok for small devices, but there are also lots of cheap HW implementation, e.g. you can get chips for $0.60)

Citrullin commented 3 years ago

There is a small list for crypto ICs.

mmccool commented 3 years ago

So... different elliptic curves can be used with ECDSA/EdDSA. Let's further specify the curve: NIST-P256, which is widely supported in HW as well. However, this is not perfect, and there are other ones that could be used in the future. Not everyone will agree on which sig is best (for example, X25519/Curve25519), so maybe we should allow multiple signatures (with different cryptosuites) as well. We might be able to deal with this with a small update (to the TD spec... 1.2?) in 2022 or so. Alternatively we just wait for 2.0 (and LDS) in 2023. We could also list both NIST-P256 and X25519 (and if they are at risk, and we can't test both, then we just drop one...). These two curves should cover the needs of most communities. And it turns out the SW implementations of X25519 are pretty fast, so...