CFRG B. Ford
Internet-Draft N. Gailly
Intended status: Informational L. Gasser
Expires: January 1, 2018 P. Jovanovic
EPFL
June 30, 2017
Collective Edwards-Curve Digital Signature Algorithm
draft-ford-cfrg-cosi-00
Abstract
Collective signatures are compact cryptographic proofs showing that
several distinct secret key holders, called cosigners, have
cooperated to sign a given message. This document describes a
collective signature extension to the EdDSA signing schemes for the
Ed25519 and Ed448 elliptic curves. A collective EdDSA signature
consists of a point R, a scalar s, and a bitmask Z indicating the
specific subset of a known group of cosigners that produced this
signature. A collective signature produced by n cosigners is of size
64+ceil(n/8) bytes for Ed25519 and 114+ceil(n/8) bytes for Ed448,
respectively, instead of 64n and 114n bytes for n individual
signatures. Further, collective signature verification requires only
one double scalar multiplication rather than n. The verifier learns
exactly which subset of the cosigners participated, enabling the
verifier to implement flexible acceptance-threshold policies, and
preserving transparency and accountability in the event a bad message
is collectively signed.
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 http://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 January 1, 2018.
Ford, et al. Expires January 1, 2018 [Page 1]
Internet-Draft Collective EdDSA Signatures June 2017
Copyright Notice
Copyright (c) 2017 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
(http://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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Notations and Conventions . . . . . . . . . . . . . . . . . . 4
4. Collective Signing . . . . . . . . . . . . . . . . . . . . . 5
4.1. Collective Public Key Setup . . . . . . . . . . . . . . . 5
4.2. Signature Generation . . . . . . . . . . . . . . . . . . 5
4.3. Signature Verification . . . . . . . . . . . . . . . . . 6
5. Collective Signing Protocol . . . . . . . . . . . . . . . . . 7
5.1. Collective Signature . . . . . . . . . . . . . . . . . . 7
5.1.1. Announcement . . . . . . . . . . . . . . . . . . . . 7
5.1.2. Commitment . . . . . . . . . . . . . . . . . . . . . 7
5.1.3. Challenge . . . . . . . . . . . . . . . . . . . . . . 8
5.1.4. Response . . . . . . . . . . . . . . . . . . . . . . 8
5.1.5. Signature Generation . . . . . . . . . . . . . . . . 8
5.2. Collective Verification . . . . . . . . . . . . . . . . . 8
6. Tree-based CoSi Protocol . . . . . . . . . . . . . . . . . . 8
6.1. CoSi Tree . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Collective Signature . . . . . . . . . . . . . . . . . . 9
6.2.1. Announcement . . . . . . . . . . . . . . . . . . . . 9
6.2.2. Commitment . . . . . . . . . . . . . . . . . . . . . 9
6.2.3. Challenge . . . . . . . . . . . . . . . . . . . . . . 10
6.2.4. Response . . . . . . . . . . . . . . . . . . . . . . 10
6.2.5. Signature Generation . . . . . . . . . . . . . . . . 11
6.3. Verification . . . . . . . . . . . . . . . . . . . . . . 11
7. Message Format . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Announcement . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Commitment . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. Challenge . . . . . . . . . . . . . . . . . . . . . . . . 12
7.4. Response . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. General Implementations Checks . . . . . . . . . . . . . 12
Ford, et al. Expires January 1, 2018 [Page 2]
Internet-Draft Collective EdDSA Signatures June 2017
8.2. Random Number Generation . . . . . . . . . . . . . . . . 12
8.3. Group Membership . . . . . . . . . . . . . . . . . . . . 13
8.4. Multiplication by Cofactor in Verification . . . . . . . 13
8.5. Related-Key Attacks . . . . . . . . . . . . . . . . . . . 13
8.6. Availability . . . . . . . . . . . . . . . . . . . . . . 13
9. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Hashing the Public Keys in the commitment . . . . . . . . 14
9.2. Hashing the bitmask in the commitment . . . . . . . . . . 14
9.3. Exception Mechanism . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11.1. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
A conventional digital signature on some statement S is produced by
the holder of a secret key k, and may be verified by anyone against
the signer's corresponding public key K. An attacker who
successfully steals or compromises the secret key k gains
unrestricted ability to impersonate and "sign for" the key-holder.
In security-critical contexts it is thus often desirable to divide
trust and signing capabilities across several parties. For example,
some threshold t out of n known parties may be required to sign a
message before verifiers consider it acceptable. A cryptographic
proof that multiple parties have cooperated to sign a message is
generally known as a multisignature.
One form of multisignature is simply a list of individual signatures,
which the verifier must check against a given policy. For example,
in a 2-of-3 group defined by three public keys, a multisignature is
simply a list of two individual signatures, which the verifier must
ensure were produced by the holders of any two distinct public keys
in the group. Multisignatures of this kind are well-established in
many contexts, such as Bitcoin multisignature wallets [BITCOIN], and
are practical when the group of signers is small.
Another form of multisignatures is based on threshold cryptography
that uses mechanisms like Shamir secret sharing [SHAMIR] enabling any
threshold t-of-n group members to create a constant-size signature
that reveals nothing about which particular set of t members signed.
This approach simplifies verification and is desirable when the
specific set of cosigners is irrelevant or privacy-sensitive. Secret
sharing based multisignatures are inappropriate when transparency is
required, though, because t colluding members can potentially sign a
bad message but then (individually) deny involvement once the
compromise is discovered. Moreover, threshold signature schemes
usually do not scale well for larger numbers of n.
Ford, et al. Expires January 1, 2018 [Page 3]
Internet-Draft Collective EdDSA Signatures June 2017
Collective signatures are compact multisignatures that convey the
same information as a list of individual signatures and thereby offer
the same transparency, but, at the same time, are comparable in size
and verification cost to an individual signature. Group members need
not coordinate for the creation of their key-pairs beyond selecting a
common elliptic curve, and verifiers can apply flexible acceptance
policies beyond simple t-of-n thresholds. Generating collective
signatures requires cooperation, but can be done efficiently at with
thousands of participants using a tree-aggregation mechanisms as done
in the collective signing (CoSi) protocol [COSI].
2. Scope
This document does not attempt to describe CoSi in the context of any
particular Internet protocol; instead it describes an abstract
protocol that can be easily fitted to a particular application. For
example, the specific format of messages is not specified. These
issues are left to the protocol implementor to decide.
3. Notations and Conventions
The following notation is used throughout the document:
o p: Prime number.
o GF(p): Finite field with p elements.
o a || b: Concatenation of (bit-)string a with (bit-) string b.
o a + b mod p: Addition of integers a and b modulo prime p.
o a * b mod p: Multiplications of integers a and b modulo prime p.
o B: Generator of the group or subgroup of interest.
o L: Order of the group generated by B.
o I: Neutral element of the group generated by B.
o X + Y: Addition of group elements X and Y.
o [a]X: Addition of X to itself a times (scalar multiplication).
o Aggregation either refers to the addition of two group elements X
and Y or to the addition of two scalars a and b.
CoSi uses the parameters of the elliptic curves Curve25519 and
Curve448 defined in Sections 4.1 and 4.2 of [RFC7748], respectively.
Ford, et al. Expires January 1, 2018 [Page 4]
Internet-Draft Collective EdDSA Signatures June 2017
Encoding and decoding of integers is done as specified in Sections
5.1.2 and 5.1.3 of [RFC8032], respectively.
4. Collective Signing
The collective signing (CoSi) algorithm is an aggregate signature
scheme based on Schnorr signatures and the EdDSA signing procedure.
CoSi signatures are non-deterministic though as they include random
participant commitments and a bitmask identifying participants that
have not contributed to the signature generation. This section first
presents the collective key setup mechanism, the abstract signature
generation algorithm and finally the signature verification
procedure.
4.1. Collective Public Key Setup
Let N denote the list of participants. First, each participant i of
N generates his longterm private-public key pair (a_i, A_i) as in
EdDSA, see Section 5.1.5 of RFC8032 [1]. Afterwards, given a list of
public keys A_1, ..., A_n, the collective public key is specified as
A = A_1 + ... + A_n.
4.2. Signature Generation
This section presents the collective signature generation scheme.
The inputs of the signature process are:
o A collective public key A generated from the public keys of
participants N.
o A subset of participants M of N who actively participate in the
signature creation. The size of M is denoted by m.
o A statement (or message) S.
The signature is generated as follow:
1. For each participant i in M, generate a random secret r_i by
hashing 32 bytes of cryptographically secure random data. For
efficiency, reduce each r_i mod L. Each r_i MUST be re-generated
until it is different from 0 mod L or 1 mod L.
2. Compute the integer addition r of all r_i: r = SUM_{i in M}(r_i).
3. Compute the encoding of the fixed-base scalar multiplication [r]B
and call the result R.
Ford, et al. Expires January 1, 2018 [Page 5]
Internet-Draft Collective EdDSA Signatures June 2017
4. Compute SHA512(R || A || S) and interpret the 64-byte digest as
an integer c mod L.
5. For each participant i in M, compute the response s_i = (r_i + c
* a_i) mod L.
6. Compute the integer addition s of all s_i: s = SUM_{i in M}(s_i).
7. Initialize a bitmask Z of length n to all zero. For each
participant i who is present in N but not in M set the i-th bit
of Z to 1, i.e., Z[i] = 1.
8. The signature is the concatenation of the encoded point R, the
integer s, and the bitmask Z, denoted as sig = R || s || Z.
4.3. Signature Verification
The inputs to the signature verification process are:
o A list of public keys A_i of all participants i in N.
o The collective public key A.
o The statement S.
o The signature sig = R || s || Z.
o A signature policy which is a function that takes a bitmask as an
input and returns true or false. For example, a basic signature
policy might require that a certain threshold of participants took
part in the generation of the collective signature.
A signature is considered valid if the verification process finishes
each of the steps below successfully.
1. Split sig into two 32-byte sequences R and s and a bitmask Z.
Interpret R as a point on the used elliptic curve and check that
it fulfills the curve equation. Interpret s as an unsigned
integer and verify that it is non-zero and smaller than L.
Verify that Z has length n. If any of the mentioned checks
fails, abort the verification process and return false.
2. Check Z against the signature policy. If the policy does not
hold, abort the verification process and return false.
3. Compute SHA512(R || A || S) and interpret the 64-byte digest as
an integer c.
Ford, et al. Expires January 1, 2018 [Page 6]
Internet-Draft Collective EdDSA Signatures June 2017
4. Initialize a new elliptic curve point T = I. For each bit i in
the bitmask that is equal to 1, add the corresponding public key
A_i to the point T. Formally, T = SUM_{i in N, Z[i] == 1}(A_i)
for all i set to 1 in the bitmask.
5. Compute the reduced public key A' = A - T.
6. Check if the group equation [8][s]B = [8]R + [8][c]A' holds.
5. Collective Signing Protocol
This section introduces the distributed CoSi protocol with n
participants. For simplicity, we assume there is a designated leader
who is responsible for collecting the shares and generating the
signature. This leader could be any of the signers and is not
trusted in any way. All participants are communicating through a
reliable channel with the leader.
5.1. Collective Signature
The leader must know the statement S to be signed and the set of
public keys of the participants N. The point A is defined as the
collective key of the participants N. A collective signature is
generated in four steps over two round trips between the leader and
the rest of the participants.
5.1.1. Announcement
Upon the request to generate a signature on a statement S, the leader
broadcasts an announcement message indicating the start of a signing
process. It is up to the implementation to decide whether to send S
itself during that phase or not.
5.1.2. Commitment
Upon the receipt of an announcement message or if the participant is
the leader, each participant i generates a random secret r_i by
hashing 32 bytes of cryptographically secure random data. Each r_i
MUST be re-generated until it is different from 0 mod L or 1 mod L.
Each participants then constructs the commitment R_i as the encoding
of [r_i]B, sends R_i to the leader and stores the generated r_i for
usage in the response phase. If the participant is the leader, it
executes the challenge step.
Ford, et al. Expires January 1, 2018 [Page 7]
Internet-Draft Collective EdDSA Signatures June 2017
5.1.3. Challenge
The leader waits to receive the commitments R_i from the other
participants for a certain time frame as defined by the application.
After the timeout, the leader constructs the subset M of participants
from whom he has received a commitment R_i and computes the sum R =
SUM_{i in M}(R_i). The leader then computes SHA512(R || A || M) and
interprets the resulting 64-byte digest as an integer c mod L. The
leader broadcasts c to all participants.
5.1.4. Response
Upon reception of c or if the participant is the leader, each
participant generates his response s_i = (r_i + c * a_i) mod L. Each
non-leader participant sends his s_i to the leader. If the
participant is the leader, he executes the signature generation step.
5.1.5. Signature Generation
The leader waits to receive the responses s_i from the other
participants for a certain time frame as defined by the application.
After the timeout, the leader checks if he received responses from
all participants in M and if not he MUST abort the protocol. The
leader then computes the aggregate response s = SUM{i in M}(s_i) mod
L and initializes a bitmask Z of size n to all zero. For each
participant i who is present in N but not in M the leader sets the
i-th bit of Z to 1, i.e., Z[i] = 1. The leader then forms the
signature sig as the concatenation of the byte-encoded point R, the
byte-encoded scalar s, and the bitmask Z. The resulting signature is
of the form sig = R || s || Z and MUST be of length 32 + 32 +
ceil(n/8) bytes.
5.2. Collective Verification
The verification process is the same as defined in the
Section "Signature Verification" above.
6. Tree-based CoSi Protocol
This section presents the CoSi protocol using a tree-shaped network
communication overlay. While the core protocol stays the same, the
tree-shaped communication enables CoSi to handle large numbers of
participants during signature generation efficiently.
Ford, et al. Expires January 1, 2018 [Page 8]
Internet-Draft Collective EdDSA Signatures June 2017
6.1. CoSi Tree
Any tree used by CoSi SHOULD be a complete tree for performance
reasons, i.e., every level except possible the last one of the tree
MUST be filled. The leader is the root node of the tree and is
responsible for creating the tree. An intermediate node is a node
who has one parent node and at least one child node. A leaf node is
a node who has only one parent and no child nodes.
We define the BROADCAST operation as:
o The leader multicasts a message to his direct child nodes.
o Upon reception of a message, each node stores the message and
multicasts it further down to its children node, except if the
node is a leaf.
The internal representation of the tree, and its propagation to the
participants is left to the application.
6.2. Collective Signature
The leader must know the statement S, the set N of the participants
and their public keys, and the subset M of active participants. The
actual communication tree T is created from the subset M, and MUST
contain all participants of M. The point A is defined as the
collective key of the set P.
6.2.1. Announcement
The leader BROADCASTS an announcement message. Upon reception, each
leaf node executes the commitment step.
6.2.2. Commitment
Every node must generate a random commitment R_i as described in the
previous commitment section [...]. Each leaf node directly sends its
commitment R_i to its parent node. Each non-leaf node generates a
bit mask Z_i of n bits initialized with all 0 bits and starts waiting
for a commitment and a bit mask from each of its children. After the
timeout defined by the application, each node aggregates all its
children's commitments R_i received using point addition formulas,
adds its own commitment and stores the result in R'. For every
absent commitment from a child at index j in N, the node sets the
j-th of its bit mask Z_i to 1. The node also performs an OR
operation between all the received bitmasks from its children and its
own bit mask, and let the result be B'.
Ford, et al. Expires January 1, 2018 [Page 9]
Internet-Draft Collective EdDSA Signatures June 2017
// XXX Should we reject invalid messages, like too-long-bitmask or
so? // XXX Bitmasks should be signed and checked? If the node is an
intermediate node, it sends the aggregated commitment R' alongside
with the Z' bitmask to its parents. If the node is the root node, it
executes the challenge step.
// XXX What happens when a node does not receive any commitment from
a child node. Does it contact the sub-nodes?
6.2.3. Challenge
The leader computes the challenge c = H( R' || A || S) and BROADCASTS
it down the tree. The leader also saves the bitmask Z' computed in
the previous step. Upon reception, each leaf node executes the
response step.
6.2.4. Response
Each node generates its response s_i as defined in XXX Response XXX.
Each leaf node sends its response to their parent and is allowed to
leave the protocol.
Each other node starts waiting for the responses of its children.
XXX HOW to signal / abort? Is it application dependent also? What
happens if the root times out?
For each response s received in node i from node's children j, the
node i SHOULD perform a verification of the partial response. Let t
be the sub-tree with the node j at the root, and D the aggregation of
all the public keys of the participants in t. Let V be the
aggregation of all commitments generated by all participants in t.
If the equation [8][s]B = [8]V + [8][c]D does not hold, then the node
i MUST abort the protocol.
After the timeout occurs, if at least one child's response is
missing, the node MUST signal the leader to abort the protocol.
Otherwise, each intermediate node aggregates all its children's
responses, adds its own response s_i, using scalar addition formulas
and sends the resulting scalar s' up to its parent. Each
intermediate node can now leave the protocol.
When the root node receives all the responses s' from its children,
it can generate the signature.
Ford, et al. Expires January 1, 2018 [Page 10]
Internet-Draft Collective EdDSA Signatures June 2017
6.2.5. Signature Generation
The generation procedure is exactly the same as in the XXX Generation
XXX section above.
6.3. Verification
The verification procedure is exactly the same as in the XXX Verify
XXX section above.
7. Message Format
All packets exchanged during a CoSi protocol's instance MUST be
encoded using Google's Protobuf technology [PROTOBUF]. All packets
for a CoSi protocol must be encoded inside the CoSiPacket message
format. The "phase" field indicates which message is encoded in the
packet. The CoSi packet message contains a "phase" field which is
set accordingly to the current phase of the protocol: + Announcement
= 1 + Commitment = 2 + Challenge = 3 + Response = 4
message CoSiPacket {
// Announcement = 1, Commitment = 2, Challenge = 3, Response = 4
required uint32 phase = 1;
optional Announcement ann = 2;
optional Commitment comm = 3;
optional Challenge chal = 4;
optional Response resp = 5;
}
7.1. Announcement
The Announcement message notifies participants of the beginning of a
CoSi round. Implementations can extent the message specifications to
include the message to sign. That way, participants can refuse to
vote at this step by not replying with a commitment. This do not
cause any restart of the protocol later.
message Announcement {
}
7.2. Commitment
The commitment message includes the aggregated commitment as well as
the bitmask if the tree based CoSi protocol is used.
Ford, et al. Expires January 1, 2018 [Page 11]
Internet-Draft Collective EdDSA Signatures June 2017
message Commitment {
// aggregated commitment R'
required bytes comm = 1;
// bitmask B'
optional bytes mask = 2;
}
7.3. Challenge
The challenge message includes the challenge computed by the leader
of the CoSi protocol.
message Challenge {
// commputed challenge c
required bytes chall = 1;
}
7.4. Response
The response message includes the aggregated response to be sent to
the leader.
message Response {
// aggregated response s'
required bytes resp = 1;
}
8. Security Considerations
8.1. General Implementations Checks
The checks described throughout the different protocols MUST be
enforced. Namely that includes: + the random component r MUST
conform to r != 0 mod L and r != 1 mod L. + the resulting signature
s MUST conform to s != 0 mod L during signature generation + the
signature s MUST conform to 0 < s < L + the intermediate signature at
each level of the tree MUST be verifiable correctly as described in
section the Response step in section XXX
8.2. Random Number Generation
CoSi requires a cryptographically secure pseudorandom number
generator (PRNG) for the generation of the private key and the seed
to get the random integer r. In most cases, the operating system
provides an appropriate facility such as /dev/urandom, which should
be used absent other (performance) concerns. It is generally
preferable to use an existing PRNG implementation in preference to
crafting a new one, and many adequate cryptographic libraries are
Ford, et al. Expires January 1, 2018 [Page 12]
Internet-Draft Collective EdDSA Signatures June 2017
already available under favorable license terms. Should those prove
unsatisfactory, [RFC4086] provides guidance on the generation of
random values. The hashing of the seed provides an additional layer
of security regardless of the security of the PRNG.
8.3. Group Membership
Elements should be checked for group membership: failure to properly
validate group elements can lead to attacks. In particular it is
essential to verify that received points are valid compressions of
points on an elliptic curve when using elliptic curves.
8.4. Multiplication by Cofactor in Verification
The given verification formulas multiply points by the cofactor.
While this is not strictly necessary for security (in fact, any
signature that meets the non-multiplied equation will satisfy the
multiplied one), in some applications it is undesirable for
implementations to disagree about the exact set of valid signatures.
8.5. Related-Key Attacks
Before any CoSi round happens, all the participants MUST have the
list of public keys of the whole set of participants, including a
self signature for each public key. This list MUST be generated
before any round. If it it not the case, an attacker can craft a
special public key which has the effect of eliminating the
contribution of a specific participant to the signature.
8.6. Availability
The participating servers should be highly available and should be
operated by reputable and competent organizations so the risk a of
DDOS attack by un-reliable participants is greatly diminished. In
case of failures before the Challenge phase, the leader might abort
the protocol if the threshold of present participants is too low.
If a participant detects one of its children in the tree as missing,
a simple mechanism is to return an error which propagates back up the
tree to the leader. The leader can then restart the round accounting
for this missing participant in the bitmask B described in the
Commitment section XXX.
9. Discussions
Ford, et al. Expires January 1, 2018 [Page 13]
Internet-Draft Collective EdDSA Signatures June 2017
9.1. Hashing the Public Keys in the commitment
Either do H(R || A || msg) with A being the collective public key OR
do H(R || SUM(X_i) || msg) where SUM(X_i) is the sum of all public
keys that participated in the collective signature,i.e. the
aggregation of all keys in the active participant subset Q.
9.2. Hashing the bitmask in the commitment
To truely bind one signature to a set of signers, the bitmask can be
included in the challenge computation such like H(R || A ||
bitmask || msg). The signature verification process could detect any
modifications of the original signature before proceeding the
computationally expensive process.
9.3. Exception Mechanism
XXX What to do in case a node goes offline, doesn't sign, or doesn't
relay up etc. in the tree approach.
10. Acknowledgements
Many parts of this document were inspired by RFC8032 on EdDSA.
11. References
11.1. URIs
[1] https://tools.ietf.org/html/rfc8032#page-13
Authors' Addresses
Bryan Ford
EPFL
BC 210, Station 14
Lausanne CH-1015
Switzerland
Phone: +41 21 693 28 73
Email: bryan.ford@epfl.ch
Ford, et al. Expires January 1, 2018 [Page 14]
Internet-Draft Collective EdDSA Signatures June 2017
Nicolas Gailly
EPFL
BC 263, Station 14
Lausanne CH-1015
Switzerland
Phone: +41 21 69 36613
Email: nicolas.gailly@epfl.ch
Linus Gasser
EPFL
BC 208, Station 14
Lausanne CH-1015
Switzerland
Phone: +41 21 69 36770
Email: linus.gasser@epfl.ch
Philipp Jovanovic
EPFL
BC 263, Station 14
Lausanne CH-1015
Switzerland
Phone: +41 21 69 36628
Email: philipp.jovanovic@epfl.ch
Ford, et al. Expires January 1, 2018 [Page 15]