Re: [Teep] OTrP Signature Security issue

Anders Rundgren <anders.rundgren.net@gmail.com> Wed, 21 November 2018 09:24 UTC

Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: teep@ietfa.amsl.com
Delivered-To: teep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21CB129AB8 for <teep@ietfa.amsl.com>; Wed, 21 Nov 2018 01:24:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GFJ333DFwNl for <teep@ietfa.amsl.com>; Wed, 21 Nov 2018 01:24:18 -0800 (PST)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8AF712958B for <teep@ietf.org>; Wed, 21 Nov 2018 01:24:17 -0800 (PST)
Received: by mail-wm1-x32f.google.com with SMTP id p2-v6so4955784wmc.2 for <teep@ietf.org>; Wed, 21 Nov 2018 01:24:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=w4XwLB0haGbdXtEfqLve1gN+jnhdFlTx4JyFeyPVp4w=; b=i/v1p+dmQGHh9QP28MuSnVcTXLat/f214Y5uXge5yhm/iRrLJC4v1ffcB7a87uiIF3 iksfqRd9SGyKhopqsOiRUkAQ1SXY/U6TZTknGUlxt6LOWjc4B6hfa8epSg4SIOeC0gP9 MYssM9vLly5LMAh5pILogdQtlMBdbuZ0UWDiqpGaOw/MuMUZZJXAUZaT47YrS/clrCVv O4SG5osU5sianJOlgNo2dwVtUxAHB+8y2eiKQyheAlQPaHl0DvbM6ecpDAkqICtwekqT kNN/6kVLlBE23xyEmqySbiU/jGvkCKxIZGylPlC1U1PBSnxcjOttkUqrlGIHKgzJ4THm Ucjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=w4XwLB0haGbdXtEfqLve1gN+jnhdFlTx4JyFeyPVp4w=; b=Bct/2Kp20Gjm0jLZRQ6GDX1t+Ru7s4qsbCkmQzBjxiVfER0pwrYgkVY0piCvz/dXvA Ncw4dz40h2Ee5z8ab6IWHymmGkUJBhu2bUx3nK2EDJE/wvdNBGtEAjxaUZycpWqaGmya gLgQguo58HYR0UVZSu0Bg2jmu+yLzLT9GbSX/rSXUyXq2CGsSxMhIvVKdVjRljKZkI6Y hAENhKeTk3ZAVj+xUyXOv9UtQ3g8NR3cTqKWlfU1r5CJ/IBVftDbm02SvY771aVg4bGw b7iCh0GAl8FMVNKUga5C5kuMyxB/S0C33LQRgdbVOgSCrJhSWfLsCPRiIG1nvIn0dzjE PrJA==
X-Gm-Message-State: AA+aEWa9p+nIEgMAyyo/OUTU5T/avrTeyOwcQnhtRd4ZVblGjx4bTnF5 Nmkh89i3XiGSbhLOLLAsI41IyujD
X-Google-Smtp-Source: AFSGD/X5vXuuKhNlp3kGfOUTWOdMt/HbhwxkSQe6GJpTA5nVD7xjKAgj4pwlHqzAQ6Gn6Gr9OcinIQ==
X-Received: by 2002:a1c:6a08:: with SMTP id f8mr4873105wmc.4.1542792255546; Wed, 21 Nov 2018 01:24:15 -0800 (PST)
Received: from [192.168.43.218] (64.204.136.77.rev.sfr.net. [77.136.204.64]) by smtp.googlemail.com with ESMTPSA id f2sm3737592wru.14.2018.11.21.01.24.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Nov 2018 01:24:14 -0800 (PST)
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "teep@ietf.org" <teep@ietf.org>
References: <c47a641d-3931-dc0e-100a-f6fa1a8e0593@gmail.com> <VI1PR0801MB2112317A9CE00FF39BE5C973FADA0@VI1PR0801MB2112.eurprd08.prod.outlook.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <771cd5a6-0bf4-7d2c-ebfc-557a0dba5397@gmail.com>
Date: Wed, 21 Nov 2018 10:24:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <VI1PR0801MB2112317A9CE00FF39BE5C973FADA0@VI1PR0801MB2112.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/JI9acE9qMs0ZTY9CRbtU38H4BgE>
Subject: Re: [Teep] OTrP Signature Security issue
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement <teep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teep>, <mailto:teep-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teep/>
List-Post: <mailto:teep@ietf.org>
List-Help: <mailto:teep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teep>, <mailto:teep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Nov 2018 09:24:20 -0000

On 2018-11-21 10:08, Hannes Tschofenig wrote:
> 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.

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


> 
> Ciao
> Hannes
> 
> -----Original Message-----
> From: TEEP <teep-bounces@ietf.org> On Behalf Of Anders Rundgren
> Sent: Tuesday, November 20, 2018 9:57 PM
> To: teep@ietf.org
> Subject: [Teep] OTrP Signature Security issue
> 
> 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
> 
> _______________________________________________
> TEEP mailing list
> TEEP@ietf.org
> 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.
>