Internet DRAFT - draft-tigress-sample-implementation
draft-tigress-sample-implementation
Tigress D. Vinokurov
Internet-Draft A. Bulgakov
Intended status: Informational J. L. Giraud
Expires: 13 May 2023 C. Astiz
A. Pelletier
J. Hansen
Apple Inc
9 November 2022
Transfer Digital Credentials Securely: sample implementation and threat
model
draft-tigress-sample-implementation-01
Abstract
This document describes a sample implementation of Tigress internet
draft [Tigress-00] and a threat model of this implementation.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://github.com/dimmyvi/tigress-sample-implementation. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-tigress-sample-
implementation/.
Source for this draft and an issue tracker can be found at
https://github.com/dimmyvi/tigress-sample-implementation.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 May 2023.
Vinokurov, et al. Expires 13 May 2023 [Page 1]
Internet-Draft tigress-sample-implementation November 2022
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2
3. Sample Implementation - Digital Car Key sharing example. . . 3
4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Normative References . . . . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
This document provides a sample implementation and threat model for
Tigress draft [Tigress-00].
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
* DCK - Digital Car Key
* AP - Application Processor
* TTL - Time To Live
* AAA - Apple Anonymous Attestation - a subtype of WebAuthn
[WebAuthn-2]
Vinokurov, et al. Expires 13 May 2023 [Page 2]
Internet-Draft tigress-sample-implementation November 2022
* PKI - public Key Infrastructure
* UUID - a unique identifier defined in [RFC4122]
* SMS - Short Message Service
* OS - Operating System
* URI - Uniform Resource Identifier
* URL - Universal Resource Locator
* RNG - Random Number Generator
3. Sample Implementation - Digital Car Key sharing example.
* An Owner's device (Sender) starts sharing flow with selection of
credential entitlements for the key shared - e.g. access
entitlements (allow open the car, allow start the engine, allow to
drive the car), time of sharing - e.g. from 09/01/2022 to
09/03/2022, then generates a KeyCreationRequest (per
[CCC-Digital-Key-30] ).
* The Owner's device generates a new symmetric encryption key
(Secret) and builds an encrypted KeyCreationRequest. Then it
generates an attestation data, that follows a WebAuthn API
[WebAuthn-2], specific to Apple - AAA, which covers the encrypted
content. Owner device makes a call to Relay server (Intermediary)
- createMailbox, passing over the encrypted content, device
attestation, mailbox configuration (mailbox time-to-live, access
rights - Read/Write/Delete), preview (display information)
details, its push notification token and a unique deviceClaim.
* Relay server verifies device attestation using WebAuthn
verification rules specific to attestation data used, including
verifying device PKI certificate in attestation blob. Relay
server creates a mailbox, using mailboxConfiguration received in
the request and stores encrypted content in it.
* The mailbox has a time-to-live which defines when it is to expire
and be deleted by the Relay server. This time is limited by the
value that can be considered both sufficient to complete the
transfer and secure against brute force attacks on the encrypted
content - e.g. 48 hours.
Vinokurov, et al. Expires 13 May 2023 [Page 3]
Internet-Draft tigress-sample-implementation November 2022
* Relay server generates a unique mailboxIdentifier value, that is
hard to predict - i.e. using UUID - and builds a full URL
(shareURL) referencing the mailbox - e.g.
"https://www.example.com/v1/m/2bba630e-519b-11ec-
bf63-0242ac130002", which it returns to the Owner device.
* Owner's device locally stores the shareURL and the Secret and
sends the shareURL with optional vertical in URL parameter and
mandatory secret in Fragment part (e.g.
"https://www.example.com/v1/m/2bba630e-519b-11ec-
bf63-0242ac130002?v=c#hXlr6aRC7KgJpOLTNZaLsw==") to the Friend's
device (Receiver) over SMS.
* Friend's device receives the shareURL in SMS, messaging
application makes an automatic GET call to shareURL (excluding
Fragment part - Secret) - and fetches a preview (Display
Information) html page with OpenGraph tags in the head:
<html prefix="og: https://ogp.me/ns#">
<head>
<title>Shared Key</title>
<meta content="Shared Key" property="og:title"/>
<meta content="You've been invited to add a shared digital car key to your device." property="og:description"/>
<meta content="https://example.com/displayInfo/general.png" property="og:url"/>
<meta content="https://example.com/displayInfo/general.png" property="og:image"/>
<meta content="200" property="og:image:width"/>
<meta content="100" property="og:image:height"/>
</head>
</html>
Figure 1: OpenGraph preview of a credential
* Messaging application shows a preview of the DCK on the Friend's
device that Owner wants to share with them. User accepts the
shareURL by clicking on the preview in the messaging application.
Messaging application redirects the user to wallet (credential
manager application) using a deep link mechanism embedded into the
OS.
* Wallet receives the shareURL with the Secret in the Fragment.
Friend's device checks if the Relay server is in allow-list of
accepted Relay servers.
* Wallet reads secure content from the mailbox using shareURL
(without the Fragment part) with ReadSecureContentFromMailbox
method, passing a unique deviceClaim with the request. Thus,
relay server binds the mailbox (identified by mailboxIdentifier)
with the Owner's device (with Owner's device deviceClaim at the
Vinokurov, et al. Expires 13 May 2023 [Page 4]
Internet-Draft tigress-sample-implementation November 2022
mailbox creation time) and the Friend's device (with Friend's
device deviceClaim at the first time Friend's device calls
ReadSecureContentFromMailbox for the mailbox). Now only these 2
devices are allowed to read and write secure content to this
particular mailbox. This secures the message exchange and
prevents other devices from altering the exchange between Owner
and Friend.
* Friend's device decrypts secure content using Secret and extracts
KeyCreationRequest (ref to [CCC-Digital-Key-30] specification).
* Friend's device generates a KeySigningRequest (ref to
[CCC-Digital-Key-30] specification), encrypts it with Secret and
uploads to the mailbox with UpdateMailbox call to Relay server,
providing its unique deviceClaim and push notification token.
* Relay server sends a push notification to Owner's device via Push
Notification Server.
* Owner device, having received a push notification message, reads
secure content from the mailbox using shareURL with
ReadSecureContentFromMailbox method, passing its unique
deviceClaim with the request. Owner's device decrypts secure
content using Secret and extracts KeySigningRequest (ref to
[CCC-Digital-Key-30] specification).
* Owner's device signs the Friend's device public key with Owner's
private key and creates a KeyImportRequest (ref to
[CCC-Digital-Key-30] specification). Owner's device encrypts it
with the Secret and uploads to the mailbox with UpdateMailbox call
to Relay server, providing its unique deviceClaim.
* Relay server sends a push notification to Friend's device via Push
Notification Server.
* Friend's device, having received a push notification message,
reads secure content from the mailbox using shareURL with
ReadSecureContentFromMailbox method, passing its unique
deviceClaim with the request. Friend device decrypts secure
content using Secret and extracts KeyImportRequest (ref to
[CCC-Digital-Key-30] specification). Friend's device provisions
the new credential to the wallet and deletes the mailbox with
DeleteMailbox call to the Relay server. As an additional security
measure, Friend device asks for a verification code (PIN code)
generated by Owner's device and communicated to Friend out-of-
band.
Vinokurov, et al. Expires 13 May 2023 [Page 5]
Internet-Draft tigress-sample-implementation November 2022
4. Threat Model
Threat model for the sample implementation is provided at the
following URL: [threat_model]: https://github.com/dimmyvi/tigress-
sample-implementation/blob/main/threat_model.png "Threat model for
Tigress sample implementation"
+====+============+===============+=============+=====================+===============+
|Item|Asset |Threat |Impact |Mitigation |Comment |
+====+============+===============+=============+=====================+===============+
|1 |Owner's DCK |Kicking-off |DCK becomes |1) User auth (face/ | |
| | |arbitrary key |shared with |touch ID), 2) Secure | |
| | |sharing by |arbitrary |Intent | |
| | |spoofing user |user/ | | |
| | |identity |adversary | | |
| | | |allowing them| | |
| | | |access to the| | |
| | | |Owner's car | | |
+----+------------+---------------+-------------+---------------------+---------------+
|2 |Content on |Content |Exposure of |1) Strong source of | |
| |Intermediary|recovery by |encrypted |randomness for salt, | |
| |server |brute forcing |content and |2) At least 128 bit | |
| | |secret |key |key length, 3) | |
| | | |redemption |Limitted TTL of the | |
| | | | |mailbox | |
+----+------------+---------------+-------------+---------------------+---------------+
|3 |Content on |Content |Ability to |1) Physical | |
| |Intermediary|recovery by |decrypt |separation between | |
| |server |intercepting |content on |content and secret, | |
| | |secret |Intermediary |e.g. secret sent as | |
| | | |server |URI fragment to | |
| | | | |recipient, 2) | |
| | | | |Optional second | |
| | | | |factor(e.g. Device | |
| | | | |PIN, Activation | |
| | | | |Options - please | |
| | | | |refer to CCC | |
| | | | |Technical | |
| | | | |Specification) can be| |
| | | | |proposed to the user | |
| | | | |via user notification| |
| | | | |based on security | |
| | | | |options of selected | |
| | | | |primary sharing | |
| | | | |channel (used to | |
| | | | |share URL with | |
| | | | |secret) | |
+----+------------+---------------+-------------+---------------------+---------------+
Vinokurov, et al. Expires 13 May 2023 [Page 6]
Internet-Draft tigress-sample-implementation November 2022
|4 |Content on |Access to |1) Adversary |1) Mailboxes | |
| |Intermediary|content by |can go to |identified by version| |
| |server |multiple |partner and |4 UUID defined in | |
| | |arbitrary |redeem the |[RFC4122](hard to | |
| | |users/devices |shared key, |guess/bruteforce), 2)| |
| | | |2) Adversary |Mailboxes 'tied' to | |
| | | |can send push|sender and recipient | |
| | | |notifications|(trust on first use | |
| | | | |via deviceClaim), 3) | |
| | | | |TTL limit for | |
| | | | |mailboxes, 4) | |
| | | | |Mailboxes deleted | |
| | | | |after pass redemption| |
+----+------------+---------------+-------------+---------------------+---------------+
|5 |Content on |Compromised |1) Adversary |1) Separation between| |
| |Intermediary|Intermediary |can redeem |content and secret, | |
| |server |server |the |e.g. secret sent as | |
| | | |sharedKey, 2)|URI fragment to | |
| | | |Adversary can|recipient, 2) TTL | |
| | | |send push |limit for mailboxes | |
| | | |notifications| | |
+----+------------+---------------+-------------+---------------------+---------------+
|6 |Content on |Unauthenticated|1) Adversary |1) Mailboxes | |
| |Intermediary|access to |can redeem |identified by version| |
| |server and |mailbox on |the |4 UUID defined in | |
| |Push Tokens |Intermediary |sharedKey, 2)|[RFC4122](hard to | |
| | |server |Adversary can|guess/bruteforce), 2)| |
| | | |send push |Mailboxes 'tied' to | |
| | | |notifications|sender and recipient | |
| | | | |(trust on first use | |
| | | | |via deviceClaim), 3) | |
| | | | |TTL limit for | |
| | | | |mailboxes, 4) | |
| | | | |Mailboxes deleted | |
| | | | |after pass redemption| |
+----+------------+---------------+-------------+---------------------+---------------+
|7 |Content on |User stores |Service |1) Mailboxes have | |
| |Intermediary|non-credential |abuse, |size limit, 2) | |
| |server |information in |Adversary can|Mailboxes have TTL | |
| | |mailbox (e.g. |use | | |
| | |"cat pictures")|Intermediary | | |
| | | |server as | | |
| | | |cloud storage| | |
+----+------------+---------------+-------------+---------------------+---------------+
|8 |Device PIN |Receiver device|Device PIN |Activation Options as| |
| | |compromised |can exposure |defined in | |
| | |(redemption |and |[CCC-Digital-Key-30],| |
| | |before friend) |forwarding to|Section 11.2 Sharing | |
Vinokurov, et al. Expires 13 May 2023 [Page 7]
Internet-Draft tigress-sample-implementation November 2022
| | | |an advarsary |Principles, | |
| | | | |subsection 11.2.1.3. | |
| | | | |Activation Options | |
+----+------------+---------------+-------------+---------------------+---------------+
|9 |Device PIN |Weak PIN can be|Anyone with |1) Use of strong RNG |[NIST-800-63B],|
| | |easily guessed |share URL in |as a source to |section 5.1.1.1|
| | | |their |generate Device PIN, |Memorized |
| | | |possession |2) Long enough PIN |Secret |
| | | |can guess the|(e.g. 6 digits) as |Authenticators |
| | | |PIN and |per [NIST-800-63B] | |
| | | |redeem the |recommendations, 3) | |
| | | |key |Limit the number of | |
| | | | |retries (e.g. Device| |
| | | | |PIN retry counter + | |
| | | | |limit) as per | |
| | | | |[NIST-800-63B] | |
| | | | |recommendations | |
+----+------------+---------------+-------------+---------------------+---------------+
|10 |Device PIN |Eavesdropping |PIN exposure |In person, out of | |
| | |on weak msg |would allow |band PIN transfer, | |
| | |channels/app |one with |e.g. voice channel | |
| | | |possession of| | |
| | | |share URL and| | |
| | | |Secret to | | |
| | | |redeem key | | |
+----+------------+---------------+-------------+---------------------+---------------+
|11 |Device PIN |PIN recovery |Adversary |1) Time invariant | |
| | |via timing |with shared |compare, 2) PIN retry| |
| | |attack |URL in |counter/limit | |
| | | |possession | | |
| | | |can recover | | |
| | | |PIN based on | | |
| | | |the response | | |
| | | |delay, in the| | |
| | | |case where | | |
| | | |the PIN | | |
| | | |verification | | |
| | | |is not | | |
| | | |invariant | | |
+----+------------+---------------+-------------+---------------------+---------------+
|12 |Device PIN |Device PIN |Device PIN |1) Use of strong RNG |[NIST-800-63B],|
| |retry |brute force |successful |as a source to |section 5.1.1.1|
| |counter/ | |guess |generate Device PIN, |Memorized |
| |limit | | |2) Long enough PIN |Secret |
| | | | |(e.g. 6 digits) as |Authenticators |
| | | | |per [NIST-800-63B] | |
| | | | |recommendations, 3) | |
| | | | |Limit the number of | |
Vinokurov, et al. Expires 13 May 2023 [Page 8]
Internet-Draft tigress-sample-implementation November 2022
| | | | |retries (e.g. Device| |
| | | | |PIN retry counter + | |
| | | | |limit) as per | |
| | | | |[NIST-800-63B] | |
| | | | |recommendations | |
+----+------------+---------------+-------------+---------------------+---------------+
|13 |Sharing |Messaging |Share |1) Send invitation | |
| |Invitation |channel |invitation |and Device PIN via | |
| | |eavesdropping |forwarding |different channels, | |
| | | |and DCK |e.g. Device PIN can | |
| | | |redemtion by |be shared out of band| |
| | | |malicious |(over voice), 2) Use | |
| | | |party |of E2E encrypted msg | |
| | | | |apps/chhannel | |
+----+------------+---------------+-------------+---------------------+---------------+
|14 |Sharing |Voluntary/ |DCK |Use of messaging apps| |
| |Invitation |Involuntary |redemption |with anti-forwarding | |
| | |forwarding by |before Friend|mechanisms(e.g. hide | |
| | |Friend | |link, copy/past | |
| | | | |prevention) | |
+----+------------+---------------+-------------+---------------------+---------------+
|15 |Sharing |Friend device |Share |Activation Options as| |
| |Invitation |compromise |invitation |defined in | |
| | |allow malware |forwarding |[CCC-Digital-Key-30],| |
| | |to forward |and key |Section 11.2 Sharing | |
| | |invitation to |redemption by|Principles, | |
| | |an adversary |malicious |subsection 11.2.1.3. | |
| | | |party |Activation Options | |
+----+------------+---------------+-------------+---------------------+---------------+
|16 |Sharing |User mistakenly|DCK |1) Send invitation | |
| |Invitation |shares with the|redemption by|and Device PIN via | |
| | |wrong person |adversary/not|different channels, | |
| | | |intended user|e.g. Device PIN can | |
| | | | |be shared out of band| |
| | | | |(over voice), 2) DCK | |
| | | | |revocation | |
+----+------------+---------------+-------------+---------------------+---------------+
|17 |Sharing |Owner device |Share |Activation Options as| |
| |Invitation |compromise |invitation |defined in | |
| | |allow malware |forwarding |[CCC-Digital-Key-30],| |
| | |to forward |and key |Section 11.2 Sharing | |
| | |invitation to |redemption by|Principles, | |
| | |an adversary |malicious |subsection 11.2.1.3. | |
| | | |party |Activation Options | |
+----+------------+---------------+-------------+---------------------+---------------+
|18 |Sharing |Friend device |DCK |1) Binding to | |
| |Invitation |OEM account |provisioning |deviceClaim, 2) | |
| | |take over |on |Device PIN shared out| |
Vinokurov, et al. Expires 13 May 2023 [Page 9]
Internet-Draft tigress-sample-implementation November 2022
| | | |adversary's |of band, 3) | |
| | | |device |Activation Options as| |
| | | | |defined in | |
| | | | |[CCC-Digital-Key-30],| |
| | | | |Section 11.2 Sharing | |
| | | | |Principles, | |
| | | | |subsection 11.2.1.3. | |
| | | | |Activation Options | |
+----+------------+---------------+-------------+---------------------+---------------+
|19 |User's |Phishing |1) Preview |1) Properly vet Java | |
| |credentials,|attacks |page URL |Script that is | |
| |payment card|leveraging |fragement |embedded in the | |
| |details, etc|malicious Java |contains |preview page, 2) | |
| | |Script in |encryption |Define strong content| |
| | |preview page |key - meaning|security policy | |
| | | |malicious JS | | |
| | | |could use key| | |
| | | |to decrypt | | |
| | | |contents, 2) | | |
| | | |Malicious | | |
| | | |Java Script | | |
| | | |can phish for| | |
| | | |user | | |
| | | |credentials, | | |
| | | |payment card | | |
| | | |information, | | |
| | | |or other | | |
| | | |sensitive | | |
| | | |data | | |
+----+------------+---------------+-------------+---------------------+---------------+
Table 1
5. Security Considerations
TODO Security
6. IANA Considerations
This document has no IANA actions.
7. Normative References
[CCC-Digital-Key-30]
Car Connectivity Consortium, "Digital Key Release 3", July
2022, <https://carconnectivity.org/download-digital-key-
3-specification/>.
Vinokurov, et al. Expires 13 May 2023 [Page 10]
Internet-Draft tigress-sample-implementation November 2022
[NIST-800-63B]
NIST, "NIST Special Publication 800-63B, Digital Identity
Guidelines", November 2022,
<https://pages.nist.gov/800-63-3/sp800-63b.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/rfc/rfc4122>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[Tigress-00]
Vinokurov, D., Byington, M., Lerch, M., Pelletier, A., and
N. Sha, "Transfer Digital Credentials Securely", November
2022,
<https://datatracker.ietf.org/doc/draft-art-tigress/>.
[WebAuthn-2]
W3, "Web Authentication - An API for accessing Public Key
Credentials - Level 2", April 2021,
<https://www.w3.org/TR/webauthn-2/>.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Dmitry Vinokurov
Apple Inc
Email: dvinokurov@apple.com
Alexey Bulgakov
Apple Inc
Email: abulgakov@apple.com
Jean-Luc Giraud
Apple Inc
Vinokurov, et al. Expires 13 May 2023 [Page 11]
Internet-Draft tigress-sample-implementation November 2022
Email: jgiraud@apple.com
Casey Astiz
Apple Inc
Email: castiz@apple.com
Alex Pelletier
Apple Inc
Email: a_pelletier@apple.com
Jake Hansen
Apple Inc
Email: jake.hansen@apple.com
Vinokurov, et al. Expires 13 May 2023 [Page 12]
