Tigress D. Vinokurov
Internet-Draft A. Bulgakov
Intended status: Informational J. L. Giraud
Expires: 10 May 2023 C. Astiz
A. Pelletier
J. Hansen
Apple Inc
6 November 2022
Transfer Digital Credentials Securely: sample implementation and threat
model
draft-tigress-sample-implementation-00
Abstract
This document describes a sample implementation and its threat model
of the secure transfer of digital credentials (Tigress) solution of
the corresponding Tigress Internet-draft [Tigress-00].
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."
Vinokurov, et al. Expires 10 May 2023 [Page 1]
Internet-Draft tigress-sample-implementation November 2022
This Internet-Draft will expire on 10 May 2023.
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 CarKey sharing example. . . . 3
4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 5
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
it.
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
Vinokurov, et al. Expires 10 May 2023 [Page 2]
Internet-Draft tigress-sample-implementation November 2022
3. Sample Implementation - Digital CarKey sharing example.
* An owner 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 spec).
* The owner device generates a new symmetric encryption key (Secret)
and encrypts the data. Then generates an attestation blob, that
follows a WebAuthn API, specific to Apple - AAA (Apple Anonymous
Attestation), 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 - RWD), preview
(display information) details, it's push notification token and a
unique deviceClaim.
* Relay server verifies device attestation using WebAuthn
verification rules specific to AAA, 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, time, 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 to against brute force attacks on the encrypted content
the content - e.g. 48 hours.
* Relay server generates a unique mailboxIdentifier value, that is
hard to predict - e.g. using GUID - and builds a full URL
(shareURL) referencing the mailbox - e.g. "www.example.com/v1/
m/2bba630e-519b-11ec-bf63-0242ac130002", which it returns to the
Owner device.
* Owner 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. "www.example.com/v1/m/2bba630e-519b-
11ec-bf63-0242ac130002?v=c#hXlr6aRC7KgJpOLTNZaLsw==") to the
Friend's device (Receiver) over SMS.
* Friend 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:
Vinokurov, et al. Expires 10 May 2023 [Page 3]
Internet-Draft tigress-sample-implementation November 2022
<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 the user a preview of the carKey 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 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 HTTP POST method, passing a
unique deviceClaim with the request. Relay server binds the
mailbox (identified by mailboxIdentifier) with the Owner device
(with Owner device deviceClaim) and the Friend device (with Friend
device deviceClaim). 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 specification).
* Friend device generates a KeySigningRequest (ref to CCC
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.
Vinokurov, et al. Expires 10 May 2023 [Page 4]
Internet-Draft tigress-sample-implementation November 2022
* Owner device, having received a push notification message, reads
secure content from the mailbox using shareURL with HTTP POST
method, passing its unique deviceClaim with the request. Owner
device decrypts secure content using Secret and extracts
KeySigningRequest (ref to CCC specification).
* Owner device signs the Friend's device public key with Owner's
private key and creates a KeyImportRequest (ref to CCC
specification). Owner device encrypts it with the Secret and
uploads to the mailbox with with UpdateMailbox call to Relay
server, providing its unique deviceClaim.
* Relay server sends a push notification to Friend device via Push
Notification Server.
* Friend device, having received a push notification message, reads
secure content from the mailbox using shareURL with HTTP POST
method, passing its unique deviceClaim with the request. Friend
device decrypts secure content using Secret and extracts
KeyImportRequest (ref to CCC specification). Friend 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 device and communicated to
Friend out-of-band.
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 become |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 | |
Vinokurov, et al. Expires 10 May 2023 [Page 5]
Internet-Draft tigress-sample-implementation November 2022
| | |secret |key |key lenght, 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| |
| | | | |propoused to the user| |
| | | | |via UI notification | |
| | | | |based on security | |
| | | | |options of selected | |
| | | | |primary sharing | |
| | | | |channel (used to | |
| | | | |share URL with | |
| | | | |secret) | |
+----+------------+---------------+-------------+---------------------+---------------+
|4 |Content on |Accees 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| | |
+----+------------+---------------+-------------+---------------------+---------------+
Vinokurov, et al. Expires 10 May 2023 [Page 6]
Internet-Draft tigress-sample-implementation November 2022
|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 | |
| | | |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 |reccomendations, 3) | |
| | | |key |Limit numer of | |
| | | | |retries (e.g. DEvice| |
| | | | |PIN retry counter + | |
| | | | |limit) as per | |
| | | | |[NIST-800-63B] | |
| | | | |reccomendations | |
+----+------------+---------------+-------------+---------------------+---------------+
|10 |Device PIN |Eavesdropping |PIN exposure |In person, out of | |
| | |on weak msg |would allow |band PIN trasfer, | |
| | |channels/app |one with |e.g. voice channel | |
| | | |possession of| | |
Vinokurov, et al. Expires 10 May 2023 [Page 7]
Internet-Draft tigress-sample-implementation November 2022
| | | |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] | |
| | | | |reccomendations, 3) | |
| | | | |Limit numer of | |
| | | | |retries (e.g. DEvice| |
| | | | |PIN retry counter + | |
| | | | |limit) as per | |
| | | | |[NIST-800-63B] | |
| | | | |reccomendations | |
+----+------------+---------------+-------------+---------------------+---------------+
|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| |
Vinokurov, et al. Expires 10 May 2023 [Page 8]
Internet-Draft tigress-sample-implementation November 2022
| |Invitation |compromise |invitation |defined in | |
| | |allow malware |forwarding |[CCC-Digital-Key-30],| |
| | |to forward |and key |Section 11.2 Sharing | |
| | |invitation to |redemtion 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| |
| | | |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) Landing |1) Properly vet JS | |
| |credentials,|attacks |page URL |that is embeded on | |
| |payment card|leveraging |fragement |landing page, 2) | |
| |details, etc|malicious JS on|contains |Define strong content| |
| | |landing page |encryption |security policy | |
| | | |key - meaning| | |
| | | |malicious JS | | |
| | | |could use key| | |
| | | |to decrypt | | |
| | | |contents, 2) | | |
| | | |Malicious JS | | |
| | | |can phish for| | |
| | | |user | | |
Vinokurov, et al. Expires 10 May 2023 [Page 9]
Internet-Draft tigress-sample-implementation November 2022
| | | |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 – The Future of
Vehicle Access", November 2021, <https://global-
carconnectivity.org/wp-content/uploads/2021/11/
CCC_Digital_Key_Whitepaper_Approved.pdf>.
[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>.
Vinokurov, et al. Expires 10 May 2023 [Page 10]
Internet-Draft tigress-sample-implementation November 2022
[Tigress-00]
Vinokurov, D., Byington, M., Lerch, M., Pelletier, A., and
N. Sha, "Transfer Digital Credentials Securely", September
2022,
<https://datatracker.ietf.org/doc/draft-art-tigress/>.
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
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 10 May 2023 [Page 11]