Internet-Draft tigress-sample-implementation November 2022
Vinokurov, et al. Expires 10 May 2023 [Page]
Workgroup:
Tigress
Internet-Draft:
draft-tigress-sample-implementation-00
Published:
Intended Status:
Informational
Expires:
Authors:
D. Vinokurov
Apple Inc
A. Bulgakov
Apple Inc
J. L. Giraud
Apple Inc
C. Astiz
Apple Inc
A. Pelletier
Apple Inc
J. Hansen
Apple Inc

Transfer Digital Credentials Securely: sample implementation and threat model

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."

This Internet-Draft will expire on 10 May 2023.

Table of Contents

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.

3. Sample Implementation - Digital CarKey sharing example.

<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

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"

Table 1
Item Asset Threat Impact Mitigation Comment
1 Owner's DCK Kicking-off arbitrary key sharing by spoofing user identity DCK become shared with arbitrary user/adversary allowing them access to the Owner's car 1) User auth (face/touch ID), 2) Secure Intent  
2 Content on Intermediary server Content recovery by brute forcing secret Exposure of encrypted content and key redemption 1) Strong source of randomness for salt, 2) At least 128 bit key lenght, 3) Limitted TTL of the mailbox  
3 Content on Intermediary server Content recovery by intercepting secret Ability to decrypt content on Intermediary server 1) Physical separation between content and secret, e.g. secret sent as 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 Intermediary server Accees to content by multiple arbitrary users/devices 1) Adversary can go to partner and redeem the shared key, 2) Adversary can send push notifications 1) Mailboxes identified by version 4 UUID defined in [RFC4122](hard to guess/bruteforce), 2) Mailboxes 'tied' to sender and recipient (trust on first use via deviceClaim), 3) TTL limit for mailboxes, 4) Mailboxes deleted after pass redemption  
5 Content on Intermediary server Compromised Intermediary server 1) Adversary can redeem the sharedKey, 2) Adversary can send push notifications 1) Separation between content and secret, e.g. secret sent as URI fragment to recipient, 2) TTL limit for mailboxes  
6 Content on Intermediary server and Push Tokens Unauthenticated access to mailbox on Intermediary server 1) Adversary can redeem the sharedKey, 2) Adversary can send push notifications 1) Mailboxes identified by version 4 UUID defined in [RFC4122](hard to guess/bruteforce), 2) Mailboxes 'tied' to sender and recipient (trust on first use via deviceClaim), 3) TTL limit for mailboxes, 4) Mailboxes deleted after pass redemption  
7 Content on Intermediary server User stores non-credential information in mailbox (e.g. "cat pictures") Service abuse, Adversary can use Intermediary server as cloud storage 1) Mailboxes have size limit, 2) Mailboxes have TTL  
8 Device PIN Receiver device compromised (redemption before friend) Device PIN can exposure and forwarding to an advarsary Activation Options as defined in [CCC-Digital-Key-30], Section 11.2 Sharing Principles, subsection 11.2.1.3. Activation Options  
9 Device PIN Weak PIN can be easily guessed Anyone with share URL in their possession can guess the PIN and redeem the key 1) Use of strong RNG as a source to generate Device PIN, 2) Long enough PIN (e.g. 6 digits) as per [NIST-800-63B] reccomendations, 3) Limit numer of retries (e.g. DEvice PIN retry counter + limit) as per [NIST-800-63B] reccomendations [NIST-800-63B], section 5.1.1.1 Memorized Secret Authenticators
10 Device PIN Eavesdropping on weak msg channels/app PIN exposure would allow one with possession of share URL and Secret to redeem key In person, out of band PIN trasfer, e.g. voice channel  
11 Device PIN PIN recovery via timing attack Adversary with shared URL in possession can recover PIN based on the response delay, in the case where the PIN verification is not invariant 1) Time invariant compare, 2) PIN retry counter/limit  
12 Device PIN retry counter/limit Device PIN brute force Device PIN successful guess 1) Use of strong RNG as a source to generate Device PIN, 2) Long enough PIN (e.g. 6 digits) as per [NIST-800-63B] reccomendations, 3) Limit numer of retries (e.g. DEvice PIN retry counter + limit) as per [NIST-800-63B] reccomendations [NIST-800-63B], section 5.1.1.1 Memorized Secret Authenticators
13 Sharing Invitation Messaging channel eavesdropping Share invitation forwarding and DCK redemtion by malicious party 1) Send invitation and Device PIN via different channels, e.g. Device PIN can be shared out of band (over voice), 2) Use of E2E encrypted msg apps/chhannel  
14 Sharing Invitation Voluntary/Involuntary forwarding by Friend DCK redemption before Friend Use of messaging apps with anti-forwarding mechanisms(e.g. hide link, copy/past prevention)  
15 Sharing Invitation Friend device compromise allow malware to forward invitation to an adversary Share invitation forwarding and key redemtion by malicious party Activation Options as defined in [CCC-Digital-Key-30], Section 11.2 Sharing Principles, subsection 11.2.1.3. Activation Options  
16 Sharing Invitation User mistakenly shares with the wrong person DCK redemption by adversary/not intended user 1) Send invitation and Device PIN via different channels, e.g. Device PIN can be shared out of band (over voice), 2) DCK revocation  
17 Sharing Invitation Owner device compromise allow malware to forward invitation to an adversary Share invitation forwarding and key redemption by malicious party Activation Options as defined in [CCC-Digital-Key-30], Section 11.2 Sharing Principles, subsection 11.2.1.3. Activation Options  
18 Sharing Invitation Friend device OEM account take over DCK provisioning on adversary's device 1) Binding to deviceClaim, 2) Device PIN shared out of band, 3) Activation Options as defined in [CCC-Digital-Key-30], Section 11.2 Sharing Principles, subsection 11.2.1.3. Activation Options  
19 User's credentials, payment card details, etc Phishing attacks leveraging malicious JS on landing page 1) Landing page URL fragement contains encryption key - meaning malicious JS could use key to decrypt contents, 2) Malicious JS can phish for user credentials, payment card information, or other sensitive data 1) Properly vet JS that is embeded on landing page, 2) Define strong content security policy  

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", , <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", , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc8174>.
[Tigress-00]
Vinokurov, D., Byington, M., Lerch, M., Pelletier, A., and N. Sha, "Transfer Digital Credentials Securely", , <https://datatracker.ietf.org/doc/draft-art-tigress/>.

Acknowledgments

TODO acknowledge.

Authors' Addresses

Dmitry Vinokurov
Apple Inc
Alexey Bulgakov
Apple Inc
Jean-Luc Giraud
Apple Inc
Casey Astiz
Apple Inc
Alex Pelletier
Apple Inc
Jake Hansen
Apple Inc