Subject: [Teep] OTrP Signature Security issue

From: Anders Rundgren <[email-masked]>
Date: Tue, 20 Nov 2018 21:57:08 +0100

The following is a for brevity simplified version of the OTrP signature scheme.  That OTrP rather uses the JSON serialized version of JWS has no security advantages (or disadvantages) over the JWS compact notation shown here:
{
    "carObject":  "eyetc.eyetc.xyxetc"
}

Since "carObject" isn't signed, you can replace it with anything else and the signature will still validate.

Using detached JWS combined with JCS [1,2] you sign the entire JSON object as well as getting the "payload" in clear:
{
    "carObject": {
       "brand":  "Ferrari",
       "horsePower":  "450",
       "weight":  "2357kg"
    },
    "signature": "eyetc..xyect"
}

thanx,
Anders

1] https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
2] https://mobilepki.org/jws-jcs

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Nov 2018 09:08:18 +0000

Hi Anders,

Thanks for raising this point.

I have been wondering whether a JSON encoding is the best choice for TEEP since web developers shouldn't actually be exposed to any of it.

Hence, my question to you is whether you have looked into COSE as well and whether your assessment would be different.

Ciao
Hannes

-----Original Message-----
From: TEEP <[email-masked]> On Behalf Of Anders Rundgren
Sent: Tuesday, November 20, 2018 9:57 PM
To: [email-masked]
Subject: [Teep] OTrP Signature Security issue

thanx,
Anders

_______________________________________________
TEEP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teep
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 21 Nov 2018 10:24:10 +0100

> Hence, my question to you is whether you have looked into COSE as well and whether your assessment would be different.

As far as I know (I'm not a COSE expert), COSE signatures have the same structure as JWS.  That is, they embed the signed data.
For systems depending on explicit object type identifiers like "TAInformation" in OTrP this becomes a bit of a nuisance.

I don't think the JOSE/COSE designers had anticipated this use case.  They would probably claim that OTrP is "misusing" JWS.

Since my own applications were based on the same idea as OTrP (explicit object types), I felt a need to do something about this.  After 5 years an 3 major revisions, I consider that done :-)

If you have a JCS implementation, combining it with JWS typically requires 10-20 lines of pretty trivial code.

Thanx,
Anders

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 21 Nov 2018 11:06:02 +0100

> Thanks for raising this point.

For completeness I should probably mention that there is no major problem i OTrP since the object "sub-identifier" is signed.

It does however require an additional validation step since a "TAInformation" object MUST be followed by its signed "TAInformationTBS" counterpart.

In both JWS and COSE the original message is "destroyed" (converted into an alien format) and must be recreated before it can be acted upon.

Anders

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 21 Nov 2018 11:11:56 +0100

> In both JWS and COSE the original message is "destroyed" (converted into an alien format) and must be recreated before it can be acted upon.

Embedding ≠ destroying.

(OK, the JWS one is a bit less easy to de-embed, but still trivial.)

The whole discussion is a red herring.

Grüße, Carsten

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 23 Nov 2018 07:55:04 +0100

Would it be possible getting a confirmation of my security analysis of the OTrP signature scheme?

That is, a complete signature validation MUST compare the outer (unsigned) object type ID with a mandatory inner (signed) counterpart like for the TAInformation/TAInformationTBS pair.

Note: This issue is not specific for OTrP; it applies to any system using outer level type IDs.  I only used OTrP as an example since my own designs (which had exactly the same problem), apparently weren't considered as representative.  I addressed this issue through JSON canonicalization since it supported several other use cases as well including a counter signature scheme only needing a hash a of JSON-formatted request.  The latter is completely out of scope for JOSE/COSE.

Anders
https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
https://mobilepki.org/jws-jcs

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 23 Nov 2018 08:11:06 +0000

Hi Anders,

Ignoring the details of the OTrP, if you want to have an effective signature scheme you need to hash the messages parts you are interested in protecting. Then, you sign the hash value.

What makes some of the message signature schemes complex is that you the message parts may be in multiple places of the message (which then requires arranging them before hashing) and some message parts should not be included in the hashing process itself (since they may change in transit). This is, however, not the case with OTrP.

Did this answer your message? Did I miss the point?

Ciao
Hannes

PS: FWIW we are still at a stage in TEEP where we are working our way through the architecture and hence I expect OTrP to change accordingly.

-----Original Message-----
From: TEEP <[email-masked]> On Behalf Of Anders Rundgren
Sent: Friday, November 23, 2018 7:55 AM
To: [email-masked]
Subject: Re: [Teep] OTrP Signature Security issue

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 23 Nov 2018 10:01:11 +0100

> Did this answer your message? Did I miss the point?

Well...the point I raised is (IMO) pretty generic.

I don't think the argument would be affected by possible TEEP architectural changes unless they go very deep like using a "session" concept like my SKS/KeyGen2 system does.

Note: I didn't say that the OTrP signature scheme is flawed, I only introduced a MUST (which I believe is currently missing), as well as pointing to an alternative solution based on work-in-progress.

thanx,
Anders

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 23 Nov 2018 09:16:46 +0000

Hi Anders,

Could you explain the session concept and how it could apply to OTrP/TEEP?

Where would you like to see a MUST in OTrP?

Ciao
Hannes

-----Original Message-----
From: TEEP <[email-masked]> On Behalf Of Anders Rundgren
Sent: Friday, November 23, 2018 10:01 AM
To: Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Teep] OTrP Signature Security issue

thanx,
Anders

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 23 Nov 2018 10:39:50 +0100

> Hi Anders,

Hi Hannes,

> Could you explain the session concept and how it could apply to OTrP/TEEP?

Sure.  It requires that you start by creating a shared secret.
Then you perform arbitrary operations based on that with MAC signatures and possibly encrypted data as well.
Finally, you commit.

This may not be what you need for TEEP.  KeyGen2 has a quite elaborate key management system where it would be close to technically infeasible doing things differently.  This systems also permits message aggregation at the proxy level, making complex operations more efficient network-wise.

It is not fundamentally different from secure messaging used for smart card provisioning so it is a time proven system although I added a little "twist" to it: https://priorart.ip.com/IPCOM/000215433

> Where would you like to see a MUST in OTrP?

I could have missed it (the OTrP I-D is pretty long...), but IMO the xyz/zyzTBS pairs MUST be matched as an additional (somewhat quirky) step during signature validation.

regards,
Anders