NO SECRETS

DISCLAIMER: The present page is just a draft, which summarizes all major aspects of service functioning. The completed document will be available soon.
Parameters
Speciface sets the following parameters for all the cryptography used: key size – 256 bit, elliptic curve – secp256k1, double hashing, encryption algorithm – AES. The service processes all account credentials and encryption passwords with KDF Scrypt, which is licensed under the 2-clause BSD License.
Profile data
All provided personal contact information is stored on the user’s mobile device as profile data. Besides, to be able to communicate with other users, each user of this service also needs to have a special set of additional (biometric) data. In order to produce this data, first, the user has to take a self portrait using own mobile device. Secondly, a special face recognition algorithm processes the portrait image bitmap as input data and stores on this device a result set of approximate face measurements – an embedding. Later, this embedding will be enough to distinguish a particular person among people nearby during subsequent Bluetooth LE communications. Moreover, all this information has to be registered in the Speciface network service, thus, the hash code (SHA-256) of this embedding should be passed to the network service along with this person’s contact data. Accordingly, the network service produces a result hash code (SHA-256) for the combination of these data blocks and a set of randomly-generated bytes. Finally, this result code is then stored in the hash data repository.
Data access
The following sequence of actions is taken by the Speciface service to provide access to users’ contact information. All interactions are to be created between three parties only. The first one is the inquiring device – a mobile device, which is used by the person who tries to access the registered personal data of some other person nearby – a target person. The second party is this target person’s mobile device. The third one is the Speciface network service, which is accessed only via secure Internet connections to the Speciface server.
First of all, to make further communications sensible, the target device should be used to log in as a registered user. As a response, the network service provides a set of actual digital signature public keys (ECDSA) along with a unique randomly-generated index code (32 bytes), which is to be valid for one day only. This code will be needed afterwards by the inquiring device to check the validity of provided information.
Subsequently, the inquiring person may use his or her device camera to take a portrait photo of the target person, whose contact information he or she wants to gain access to. Using the image of the target person as an input data, the aforementioned face recognition algorithm can produce a corresponding embedding, which should be kept on this device for later use. Then, the inquiring device generates an asymmetric key pair (ECDH) for further communications and requests a special permission from the network service by sending the embedding and the public key. Then, if the service grants the asked permission, it concatenates the received data with the current date and time and digitally signs (ECDSA) all at once. Then, the inquiring device broadcasts this data along with the signature by means of Bluetooth LE advertising.
Accordingly, as soon as the target person’s device receives this broadcasted data package, the registered embedding that had to be stored on this device beforehand and the just received one are compared on the target device. If it detects that these two embeddings are made by using images of the same target person, the provided timestamp is sufficiently recent and the digital signature is valid, it may respond with the requested data. In order to do so, it should produce its own asymmetric key pair (ECDH), build a shared secret key (ECDH, SHA-256), encrypt a special data package using this key and send this package along with own public key via Bluetooth LE connection to the inquiring device. This package should contain the target person’s registered embedding, the target person’s registered personal contact information along with the same set of randomly-generated bytes that was used upon registration and the corresponding index code.
Then, as soon as this package arrives to the inquiring device, it uses the received public key to rebuild the shared secret key (ECDH, SHA-256) and decrypts the package with it. Upon successful decryption, the received embedding and the stored one are compared on this device too. If they were made by using images of the same target person, a hash code is produced on the inquiring device the same way it was made during the described registration process. Then, the inquiring device requests a data validation check from the network service by providing this hash code along with the received index code. Accordingly, the service uses this index code to fetch a registered hash code from the hash data repository and then compares it against the provided one. If these hash codes are identical, the network service should respond with a positive status to the inquiring device, which has to display then the corresponding personal contact information.
Participants’ data
There is an alternative access method, which was added specifically for events. First of all, every web resource owner, who wants to provide information about participants, needs to have own user account, registered in Speciface service. The method implies that the resource owner is able to obtain portrait photos of every person whose data he or she wants to represent on his or her web resource. Then, by using some suitable device, the owner will need to build a set of individual embeddings for all these people. After that, a cryptographic hash function (SHA-256) is applied to each of these embeddings to generate a set of corresponding hash codes. These codes, which are represented as alphanumeric sequences, are then used on the web resource as the new names for these web pages.
The resource owner should provide the Uniform Resource Identifier (URI) of his or her web resource to the Speciface network service prior to using the aforementioned function. This URI should include all data that will be necessary to access this web resource successfully; however, it should exclude any particular web page name. A unique resource identification code is then generated by the network service to use it as an index for this URI in the repository of web resource identifiers. This code is also returned to the owner’s device and stored there along with the aforementioned set of embeddings. At last, the owner’s device requests a set of individual validation codes for all the participants from the network service. These codes are to be embedded into the corresponding web pages.
At the event
Almost the same data access procedure that was mentioned before is applied here. The main difference here is that the resource owner’s device is used here instead of the target person’s device. Moreover, the content of the package this device responses with should include only the found matching embedding and the resource identification code. Accordingly, as soon as this package arrives to the inquiring device, it compares these two embeddings and in case of a positive result, a hash code of the received embedding is produced with the same cryptographic function (SHA-256) and stored on the inquiring device. The inquiring device is used then to request a Uniform Resource Identifier of web resource by providing the resource identification code to the network service. Then, as soon as this URI is successfully delivered to the inquiring device, it should be concatenated there with the alphanumeric representation of the previously generated hash code of the embedding to rebuild a full Uniform Resource Locator. This locator should be used then on the inquiring device to access the corresponding web resource. At last, the inquiring device extracts the validation code from the received web page and requests its validation from the network service. In case it confirms the correctness of this code, the inquiring device displays the received web page, which provides necessary contact information about the target person.
PATENT PENDING