From 6cfeffca9f8e93e45dd885702a77896e2a1d0951 Mon Sep 17 00:00:00 2001 From: Ulf Wiger Date: Sun, 6 Dec 2015 13:54:17 -0800 Subject: new protocol & setup scripts --- doc/rvi_protocol.md | 34 ++++++++++++++++++---------------- 1 file changed, 18 insertions(+), 16 deletions(-) (limited to 'doc') diff --git a/doc/rvi_protocol.md b/doc/rvi_protocol.md index ab1de75..e59c0ac 100644 --- a/doc/rvi_protocol.md +++ b/doc/rvi_protocol.md @@ -134,7 +134,7 @@ functions are (for now) outside the scope of the RVI Core protocol. ## Double connect resolution There is a risk that two parties try to initiate a connection to each other in a race condition, creating two connections between them, as -shown below. +shown below. Connection 1 | Connection 2 :------:|:------: @@ -402,6 +402,8 @@ Parameter | Required | Description --device\_cert | Yes | The PEM-encoded device X.509 certificate to embed into the credential as the device_cert member. --invoke | Yes | Space separated list (within quotes) of RVI service prefixes that the owner of the credential has the right to invoke. --register | Yes | Space separated list (within quotes) of RVI service prefixes that the owner of the credential has the right to register for others to call (with the right credential). +--start | No | The Unix timestamps when the credential becomes active. +--stop | No | The Unix timestamps when the credential becomes inactive. The generated ```insecure_credential.json``` and ```insecure_credential.jwt``` are checked into ```priv/sample_credentials```. @@ -616,7 +618,7 @@ certificates with a private root key. Devices with the corresponding public root key will be able to authenticate signed device keys and authorize signed certificates. -### Root key +### Root key A root key, a 4096+ bit RSA key pair, is generated once for an issuer of certificates. The private key is stored in the certificate issuer's servers and is not shared. The public key is manually @@ -641,12 +643,12 @@ and is not shared. The public part of the key is used in two ways: Embdded in the authenticate packet are one or more certificates proving the sending RVI node's right to register and invoke services. The certificate, signed by the private root key of the - issuer, contains the public key of the sending device encoded as + issuer, contains the public key of the sending device encoded as JWT structure. This public device key can be used by a receiver to verify the signature of a service invocation requests sent by the remote RVI node. -### Certificate +### Certificate A certificate is a JSON Web Token, signed by the private root key of the certificate issuer, that proves that the RVI node with a given @@ -782,7 +784,7 @@ private root key stored in ```my_root_key_priv.pem```, generated above. The RVI node itself is never aware of that file. The RVI node does need the public root key, stored in ```my_root_key_pub.pem```, -is referenced from the RVI's configuration file stored +is referenced from the RVI's configuration file stored as ```{ rvi_core, { provisioning_key, "..../my_root_key_pub.pem" }}```. @@ -812,20 +814,20 @@ Once executed, three files will be created: 1. **```my_device_key_priv.pem```**
This file contains the private/public key pair that must never leave - the device's trusted environment. It will be used to sign + the device's trusted environment. It will be used to sign outgoing service invocation request. 2. **```my_device_key_pub.pem```**
- This file contains the public-only key that is to be added to + This file contains the public-only key that is to be added to certificates issued for the device by a certificate issuer. - + 3. **```my_device_key_pub_sign.jwt```**
This file contains the public-only key, signed by the root key, that is to be provided as authentication when an RVI node identifies itself toward another. The file is stored in JSON Web Token format. -#### Configuring RVI to use a device key +#### Configuring RVI to use a device key The RVI node needs the device private/public key root key, stored in ```my_device_key_priv.pem```, is referenced from the RVI's configuration @@ -901,9 +903,9 @@ Once executed, one mandatory and one optional file will be created: This file contains the generated certificate, signed by the private root key specified by ```--root_key=```. The content of this file will be provided by an RVI node to prove its righ - to register and invoke services toward remote RVI nodes + to register and invoke services toward remote RVI nodes + - 2. **```my_cert.json```**
Only created if ```--cert_out=``` has been give. Contains a human readable JSON form of the generated root key. @@ -931,10 +933,10 @@ the control of the provisioning server. An device-specific key pair is generated by device and stored locally. The app has one pre-provisioned certificate, signed by the -root server, allowing it to invoke ```jlr.com/provisioning/init_setup``` +root server, allowing it to invoke ```jlr.com/provisioning/init_setup``` and ```jlr.com/provisioning/request_provisioning```. The certificate also -provides the right to register ```jlr.com/mobile/*/dm/cert_provision``` -and ```jlr.com/mobile/*/dm/signed_pub_key_provision``` +provides the right to register ```jlr.com/mobile/*/dm/cert_provision``` +and ```jlr.com/mobile/*/dm/signed_pub_key_provision``` The certificate keys section, normally holding public device keys, is empty. @@ -954,7 +956,7 @@ setup an initial contact. The command contains no key, only a single pre-provisioned node certificate giving the device the right to invoke and register the functions listed in above.
- + 3. Server sends authenticate to device
The server's public device key, signed by the root private key, is sent together with no node certificates, thus giving the server no @@ -1116,7 +1118,7 @@ state through a invocation to ```jlr.com/mobile/1234/confirm_unlock``` ### Thwarting self-provisioning process - Replay TBD. -The provisioning server, having matched the side band address (MSISDN) against an internal database of devices and their access rights, will create a specific certificate only for that device.  +The provisioning server, having matched the side band address (MSISDN) against an internal database of devices and their access rights, will create a specific certificate only for that device. Given that the side band network has not been compromised, I can't see how a MITM / replay attack can give a remote remote attacker the ability to gain access of the root-signed public device key and/or use a certificate. -- cgit v1.2.1