7.1.3 Algorithmic D etails - FTP

Doc# 81897873
Change Request
CHANGE REQUEST
Meeting ID:*
SEC 29
Source:*
Yanjiang Yang, Huawei, [email protected]
Jie Shi, Huawei, [email protected]
Guilin Wang, Huawei, [email protected]
Date:*
2017-05-13
Reason for Change/s:*
Algorithm details for the existing solutions
CR against: Release*
<Release> Only ONE Release shall be indicated
CR against: WI*
Active WI-0066
MNT maintenance / < Work Item number(optional)>
Is this a mirror CR? Yes
No
mirror CR number: (Note to Rapporteur - use latest agreed revision)
STE Small Technical Enhancements / < Work Item number (optional)>
Only ONE of the above shall be ticked
CR against: TS/TR*
TR-0041 and V0.2.0
Clauses *
7.1.2 and 7.1.3
Type of change: *
Editorial change
Bug Fix or Correction
Change to existing feature or functionality
New feature or functionality
Only ONE of the above shall be ticked
Impacted other
TS/TR(s)
TR-0041
Post Freeze checking:*
This CR contains only essential changes and corrections? YES
NO
This CR may break backwards compatibility with the last approved version
of the TS?
YES
NO
Template Version: January 2017 (Do not modify)
1
2
oneM2M Notice
3
4
The document to which this cover statement is attached is submitted to oneM2M. Participation in, or attendance at, any
activity of oneM2M, constitutes acceptance of and agreement to be bound by terms of the Working Procedures and the
© 2017 oneM2M Partners
Page 1 (of 7)
Doc# 81897873
Change Request
5
6
7
Partnership Agreement, including the Intellectual Property Rights (IPR) Principles Governing oneM2M Work found in
Annex 1 of the Partnership Agreement.
© 2017 oneM2M Partners
Page 2 (of 7)
Doc# 81897873
Change Request
8
GUIDELINES for Change Requests:
9
Provide an informative introduction containing the problem(s) being solved, and a summary list of proposals.
10
Each CR should contain changes related to only one particular issue/problem.
11
12
In case of a correction, and the change apply to previous releases, a separate “mirror CR” should be posted at the same
time of this CR
13
Mirror CR: applies only when the text, including clause numbering are exactly the same.
14
Companion CR: applies when the change means the same but the baselines differ in some way (e.g. clause number).
15
16
17
Follow the principle of completeness, where all changes related to the issue or problem within a deliverable are
simultaneously proposed to be made E.g. A change impacting 5 tables should not only include a proposal to change
only 3 tables. Includes any changes to references, definitions, and acronyms in the same deliverable.
18
Follow the drafting rules.
19
All pictures must be editable.
20
Check spelling and grammar to the extent practicable.
21
Use Change bars for modifications.
22
23
24
The change should include the current and surrounding clauses to clearly show where a change is located and to provide
technical context of the proposed change. Additions of complete clauses need not show surrounding clauses as long as
the proposed clause number clearly shows where the new clause is proposed to be located.
25
26
Multiple changes in a single CR shall be clearly separated by horizontal lines with embedded text such as, start of
change 1, end of change 1, start of new clause, end of new clause.
27
28
When subsequent changes are made to content of a CR, then the accepted version should not show changes over
changes. The accepted version of the CR should only show changes relative to the baseline approved text.
29
Introduction
30
The present CR proposes algorithm details for the existing solution of decentralized authentication.
31
-----------------------Start of change 1-------------------------------------------
32
7
33
-----------------------End of change 1---------------------------------------------
34
-----------------------Start of change 2-------------------------------------------
35
7.1.2 Detailed Solution
36
37
In this framework, an IBC credential is provisioned to each entity, and two entities authenticate each other using
(D)TLS handshake with PSK ciphersuite.
38
39
Figure 7.1.2-1 shows the sequence of events in this decentralized authentication framework using IBC credentials,
wherein “Entity A” and “Entity B” could be either a CSE or an AE.
Solutions
© 2017 oneM2M Partners
Page 3 (of 7)
Doc# 81897873
Change Request
A (AE/CSE)
B (AE/CSE)
Credential Configuration
(IdA, SkA, MPK) & (IdB, SkB, MPK) are provisioned to A and B respectively
Association Security Handshake: (D)TLS Handshake
1. TLS message: ClientHello with PSK ciphersuite
2. TLS message: ServerHello, Certificate*, ServerKeyExchange,
CertificateRequest*, ServerHelloDone where the psk_identity_hint
in ServerKeyExchange is set to IdB
3. computes K =
KeyGen(IdB, SkA, MPK)
and sets TLS psk
parameter to be K
4. TLS message: Certificate*,ClientKeyExchange,
CertificateVerify*, [ChangeCipherSpec] Finished where the
psk_identity in ClientKeyExchange is set to IdA
5. computes K =
KeyGen(IdA, SkB, MPK)
and sets TLS psk
parameter to be K
6. TLS message: [ChangeCipherSpec], Finished
40
* Inclusion of these TLS message depends on the selected ciphersuite
41
Figure 7.1.2-1: The sequence of events in decentralized authentication using IBC credentials
42
43
44
45
Credential Configuration: IBC credentials (IdA, SkA, MPK) and (IdB, SkB, MPK) are provisioned to entity A and
entity B respectively, where IdA and IdB are the identities of entity A and entity B respectively, SkA and SkB are the
private keys corresponding to IdA and IdB respectively, and the MPK is the master public key which is a public system
parameter. Details of IBC credentials and their use in (D(TLS)-PSK handshake will be given in Clause 7.1.3.
46
47
48
Association Security Handshake: The entities shall perform a (D)TLS PSK handshake with IBC credentials to
establish a secure session. The details are described as follows, where unless specified, TLS messages remain the same
as in the original (D)TLS PSK handshake.
49
50
1. Entity A initiates TLS with B using a TLS PSK ciphersuite, i.e., Entity A sends a TLS ClientHello message with
PSK ciphersuite to entity B.
51
52
2. Entity B returns TLS message ServerKeyExchange, in which the psk_identity_hint in ServerKeyExchange is set to
IdB.
53
54
55
3. After receiving ServerKeyExchange message, entity A retrieves IdB, computes a key K = KeyGen(IdB, SkA, MPK)
and sets TLS psk parameter to be K, which will be used to authenticate entity B. Here, the function KeyGen can be
implemented using different techniques, and two particular implementations are described shortly.
56
57
4. Entity A sends TLS message ClientKeyExchange and Finished, where the psk_identity in ClientKeyExchange is set
to IdA;
58
59
60
5. After receiving ClientKeyExchange, entity B retrieves IdA, computes a Key K = KeyGen(IdA, SkB, MPK), and sets
TLS psk parameter to be K, which will be used to authenticate entity A. Here, the function KeyGen can be
implemented using different techniques, and two particular implementations are described shortly.
61
6. Entity B sends TLS message Finished to A and completes the TLS PSK handshake.
© 2017 oneM2M Partners
Page 4 (of 7)
Doc# 81897873
Change Request
62
63
-----------------------End of change 2---------------------------------------------
64
-----------------------Start of change 3-------------------------------------------
65
7.1.3 Algorithmic Details
66
67
The IBC credential and the KeyGen algorithm based on the Elliptic Curve-Based Certificateless Signatures specified in
[i.2] is provided.
68
7.1.3.1 Master Public Key
69
70
71
PKG, equivalent to KMS (Key Management Service) in [i.2], is responsible for establishing MPK and MSK in a setup
phase. MPK includes the Static Parameters and the Community Parameters defined in Section 4 of [i.2]. For the purpose
of exposition, we list the relevant Static Parameters in [i.2] as follows and refer more details to [i.2] :
N
P
E
B
G
Q
hash
A security parameter; the size in bits of the prime p over which
elliptic curve cryptography is to be performed.
A prime number of size n bits. The finite field with p elements is
denoted F_p
An elliptic curve defined over F_p, having a subgroup of prime
order q
An element of F_p, where E is defined by the formula y^2 = x^3 3*x + B modulo p
A point on the elliptic curve E that generates the subgroup of
order q
The prime q is defined to be the order of G in E over F_p
A cryptographic hash function mapping arbitrary strings to strings
of N octets, where N = Ceiling(n/8) is the number of
octets output by the hash function
72
73
74
75
76
77
78
79
80
The Community Parameters in [i.2] are KPAK, which is the KMS Public Authentication Key. KPAK is derived from
the KSAK (KMS Secret Authentication Key) in KMS as KPAK = [KSAK]G, where the KSAK MUST be chosen to be
a random secret non-zero integer modulo q and MUST be kept secret to the KMS. The MSK in our instantiation is
KSAK.
81
82
83
84
85
86
87
88
89
90
91
92
93
94
In Section 5.1 [1.2], user key material is defined as a (SSK, PVT) pair, where SSK is Secret Signing Key and PVT is
Public Validation Token. The SSK MUST be kept secret, but the PVT need not be kept secret. The algorithm to
generate (SSK, PVT) pair is defined in Section 5.1.1 of [i.2] and specified as follow.
As a result, MPK = (n, p, E, B, G, q, Hash, KPAK) and MSK = (KSAK).
7.1.3.2 IBC Credential
Let IDU be the identitifier of an entity U. A (SSKU,PVTU) pair is constructed from IDA by KMS through the following
procedures:
1) Choose vU, a random (ephemeral) non-zero element of F_q;
2) Compute PVTU = [vU]G;
3) Compute a hash value HSU = hash(G || KPAK || IDU|| PVTU), an N-octet integer;
4) Compute SSKU = (KSAK + HSU * vU) modulo q;
5) If either the SSKU or HSU is zero modulo q, the KMS MUST erase the SSKU and abort or restart the procedure
with a fresh value of vU;
6) Output the (SSKU, PVTU) pair. The KMS MUST then erase the value v.
© 2017 oneM2M Partners
Page 5 (of 7)
Doc# 81897873
Change Request
95
96
97
98
Given (SSKU, PVTU) for entity U, the IBC credential (IdU, SkU, MPK) for entity U is specified to be IdU = (IDU,
PVTU) and SkU = SSKU.
7.1.3.2 KeyGen Algorithm
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
Let entity A and entity B in Figure 7.1.2-1 have IBC credentials (IdA = (IDA,PVTA), SkA = SSKA, MPK) and (IdB =
(IDB,PVTB), SkB = SSKB, MPK), respectively, where PVTA = [vA]G, SSKA = KSAK + HSA*vA modulo q, PVTB =
[vB]G, SSKB = KSAK + HSB*vB modulo q, with vA and vB being two random non-zero element of F_q, HSA =
hash(G||KPAK||IDA||PVTA) and HSB = hash(G||KPAK||IDB||PVTB). The key generation function is defined as follows.
125
-----------------------End of change 3---------------------------------------------
126
-----------------------Start of change 4-------------------------------------------
127
7.1.4 Evaluation
128
-----------------------End of change 3---------------------------------------------
129
130
CHECK LIST
KeyGen for A
Input: IdB = (IDB, PVTB), SkA = (KSAK + HSA*vA) modulo q, MPK
Output: KA – an elliptic curve point
1) Parse IdB into IDB and PVTB;
2) Compute HSB = hash(G||KPAK||IDB||PVTB);
3) Compute TMP = KPAK + [HSB]PVTB;
4) Compute KA = [SSKA]TMP;
5) Output KA.
KeyGen for B
Input: IdA = (IDA,PVTA), SkB = (KSAK + HSB*vB) modulo q, MPK
Output: KB – an elliptic curve point
1) Parse IdA into IDA and PVTA;
2) Compute HSA = hash(G||KPAK||IDA||PVTA);
3) Compute TMP = KPAK + [HSA]PVTA;
4) Compute KB = [SSKB]TMP;
5) Output KB.
Note: It is oblivious that KA = KB, as KA = [SSKA]TMP = [SSKA](KPAK + [HSB]PVTB) = [(KSAK + HSA*vA][ KSAK
+ HSB*vB]G and KB = [SSKB]TMP = [SSKB](KPAK + [HSA]PVTA) = [(KSAK + HSB*vB][ KSAK + HSA*vA]G;
131
132
 Does this Change Request include an informative introduction containing the problem(s) being solved, and a
summary list of proposals.?
133
 Does this CR contain changes related to only one particular issue/problem?
134
 Have any mirror CRs been posted?
135
136
137
 Does this Change Request make all the changes necessary to address the issue or problem? E.g. A change
impacting 5 tables should not include a proposal to change only 3 tables?Does this Change Request follow the
drafting rules?
138
 Are all pictures editable?
139
 Have you checked the spelling and grammar?
© 2017 oneM2M Partners
Page 6 (of 7)
Doc# 81897873
Change Request
140
 Have you used change bars for all modifications?
141
142
143
 Does the change include the current and surrounding clauses to clearly show where a change is located and to
provide technical context of the proposed change? (Additions of complete clauses need not show surrounding
clauses as long as the proposed clause number clearly shows where the new clause is proposed to be located.)
144
145
 Are multiple changes in this CR clearly separated by horizontal lines with embedded text such as, start of change
1, end of change 1, start of new clause, end of new clause.?
146
© 2017 oneM2M Partners
Page 7 (of 7)