DicePassword (the organisation or the programmer) has no way to access a user's data; cannot know a user's password and there is no backdoor into the system to aid recovery of an account if a user forgets his/her password. This presents two problems:

When a user forgets their password and has no KeyBuddy the account can never be recovered. A user's stored assets do not identify their owners.

Law enforcement agencies cannot see a user's data and the DicePassword organisation cannot help them. The data created by DicePassword cannot be queried.

To overcome these (limitations?) will render the DicePassword application insecure and there is no intention to do that.

 

There are six topics that describe how the Murton technology works:

​

Cryptography

Murton Container - a cryptographically secure container for any kind of data

Storage - leveraging ubiquitous cloud storage services like Amazon S3 and Microsoft Azure

Sharing Model - establishes relationships between trusted users who can have private chats and share documents

Personal Object Data Schema - 

Server - there is NO server

Chat - secure inter-personal chats using Eye-to-Eye Encryption

​

Cryptography

DicePassword uses a variety of industry-standard cryptographic algorithms:

AES using 256 bit keys in Cipher Block Chaining Mode (moving to Galois Counter Mode)

RSA using 4096 bit keys (Author keeping an eye on progress of post quantum cryptography)

Diffie Hellman key agreement using Elliptic Curve

SHA256 hashing and key derivation functions

​

At registration, each user is provided with a 'KeyBundle', a highly protected object containing all of the user's keys that will be needed over the lifetime of the product. Each KeyBundle contains the following (and more) keys:

RSA Encryption Key Pair

RSA Signing Key Pair

Container AES Storage Key

SecretKeeper AES Storage Key

RootKey - dynamically maintained salt for creating AES keys. This Key is created by a manual process that converts random mouse moves into a 256 bit Key. This key is ratcheted on each use, to eliminate the predictability of the system's random number generator.

​

DicePassword does not use X.509 Certificates for two reasons:

They are too expensive for personal use in a global scale application

They are not sufficient evidence of identity to be useful in the intended markets for the Murton technology

Where it would be essential for a professional (Notary, IFA perhaps) to use their certificates for signing documents, these are perfectly compatible with RSA keys used by DicePassword (they would need to be imported (not implemented at this time))

​

Murton Container

The container is the smallest atomic unit of storage and each consists of four major sections:

​

MetaData describing the container

Content

Digital signatures and Timestamps - evidence of ownership and moment of creation 

Access Control Records - who can read the container's content (including just the owner)

Each container's content is uniquely encrypted with a 'Session Key'. The session key is encrypted with each permitted user's Encryption Public Key. The Session Key is never accessible in an unencrypted state whilst data is in transit or at rest.

Container content can be any kind of data that can be serialised to a text stream including serialised objects, binary data and file contents.

Each container is further encrypted with a 'Storage Key' for transit and data at rest. DicePassword does not rely on cloud services security for its own security. Where it is available that will be used as well, including the TLS encryption to be expected of those services while data is in transit.

​

Storage

The Murton Storage system creates a simple interface to most on-line and cloud storage services. Stored items are identified by their 'StorageID', a GUID at the present time. The interface to all attached storages is:

bool Exists(string StorageID) - returns true if an object identified by StorageID exists in the storage service

void Put(string StorageID, string Blob) - stores Blob (Blob = 'Binary Large Object', a big bunch of encrypted data) in the storage service using StorageID as its identifier. If the object already exists, it is overwritten.

string Get(string StorageID) - returns the content of the Blob from storage having the ID 'StorageID'

void Remove(string StorageID) - removes the item given by StorageID from the storage service

There are three storage types:

Primary storage - where data containers are ordinarily read from 

Secondary storage - backup storage

Local storage / Offline storage - optionally allows users to work with containers while an internet connection is unavailable. Synchronisation to Primary and Backup storage can be performed at any time there is an internet connection

Device storage (not yet implemented) allows a disk drive/SSD or memory stick to be used as a Secondary Storage service (not recommended, but offers users an obvious choice of backup). The use of locally attached storage devices for Containers does not weaken the system's security

DicePassword supports the Microsoft Azure Storage and Amazon S3 cloud storage services. These have excellent capabilities: security, availability and scalability; they are fast, reliable and inexpensive. 

​

An essential feature of any cloud storage service is that it can or does replicate all user data to at least three geographically distinct data centres. Many would say that this obviates the need for a backup, which is why DicePassword does a backup. If three large fish gnawed their way through Microsoft's transatlantic internet cabling, it is unlikely they would be so hungry after that as to do the same to Amazon's.

​

Other cloud storage services will be added over time.

​

Sharing Model

To understand how this works we need to understand the real world interactions of people in the system. A DicePassword user will have chosen the product as a Password Manager primarily, but may also be interested in other features of the technology like 'Chat' that allows the user to communicate with other DicePassword users. These other users are called 'Secret Keepers' and this name is intended to emphasise the need for collaborating users to be trusted, trustworthy and thoroughly good eggs. If not, don't do it!

A Secret Keeper is any other DicePassword user that you know and trust and the method of adding a new Secret Keeper is quite simple but cryptographically rigorous. Also, and as a measure of your closeness to a Secret Keeper, they can see all of your Identity information. If you do not know the person well enough or don't trust them enough, don't make them a Secret Keeper. You can do the following with a Secret Keeper:

 

Have perfectly private chat-style conversations (these are one-to-one at the present time)

Invite a Secret Keeper to become a 'KeyBuddy' (see below)

Share documents (Word et al)

Digitally sign documents using your signing key

​

You can dismiss a Secret Keeper at any time after which any shared documents will be hidden from them. Where document have been digitally signed by both parties, it will require the permission of both parties to be unbound by any legal obligations (not implemented yet - indeed, interactions and workflows between individuals and businesses will require much extra work)

K

Key Buddy

A Key Buddy is a Secret Keeper who becomes a guardian of your KeyBundle (your encryption keys) that may allow you to recover your account when you forget your password. A KeyBuddy does not have access to your account and will never know your sign in information. Their role is to assist in the workflow for recovering the account in a timely manner to suit you. You can have any number of KeyBuddies. Technically, your KeyBuddy will encrypt your KeyBundle with their keys to eliminate any vulnerabilities in the exchanges.

 

Personal Object Data Schema

DicePassword's data model could, in another life, be a database and to an extent that a comparison is possible, I will make a brief analogy to that. In fact, The schema entities are distinct Serialised Objects stored in Primary and Secondary cloud storage. The top level 'Table' (object) is called 'CloudNavigation' and contains pointers (ForeignKeys) to other objects in the schema. These objects can be at a single level or contain collections. Collections themselves can contain other collections as needed. Each object (Table) is stored in a MurtonContainer and is, therefore, uniquely encrypted. Further, whenever an object is updated it will be encrypted with a different key before being stored.

​

The schema's top-level table contains no clear text attributes or properties about the individual who owns it and there are no child tables having intelligible clear text attributes. All data is encrypted.

​

The schema is missing a vital entity of a conventional database schema: there is no 'Users' table  or entity at the very top level. Therefore, the community of DicePassword users has no representation in the schema: that community cannot be queried even if you could decrypt the results. This isolation of individuals provides another layer of security and privacy for DicePassword users.

​

The StorageID of the CloudNavigation object is revealed only when the user signs into the product using his or her high-entropy passphrase. Currently the schema looks like this:

CloudNavigation

StorageOptions (1 to 1)​

Identity (1 to 1)

Validations (1 to many)​

Secret Keepers (1 to many)​

Chat​ (1 to 1)

SharedDocuments​ (1 to many)​

Websites (1 to many)

Password History (1 to many)

KeyBundle (1 to 1)

Chargeable Events (1 to many)

GroupChats (1 to many)

SecretKeepers (1 to many)​

SharedDocuments (1 to many)

​

​

Serverless operation

As with the original version of Skype (the technology ran on each user's devices), the DicePassword organisation needs some way to perform account management. This is needed to take payments from users and to track the use of resources for each user's activities in each billing period. At the present time I do not know how that can be achieved so that users  can remain anonymous within the system but still be able participate in the commercial transactions. Current thinking is that users will 'push' money through BACS, rather than 'pull' money through credit/debit cards. At each signin DicePassword will seek permission to proceed from the Account Management application after informing it of the last session's attributable costs. This handshake can be anonymous if there are no legal obstacles.

​

"NKYC", not knowing your customer, is an interesting concept isn't it?

[KYC =  Know Your Customer]

​

It is assumed that the serverless methodology reduces considerably the possibility of MitM attacks. This is not a statement of fact, but a challenge.

​

Chat

Current and archived chat messages are stored in Murton Containers that provide more than adequate security for their contents. Currently, only one-to-one chats are supported (group chats have simply not yet been implemented) but the implementation is very simple:

Each chat member writes messages into a collection in a shared container that belongs to them. These are stored (as always) in the cloud. The container's SessionKey is different for each occasion that a Chat container is saved.

On doing so the message recipient is sent an Azure Service Bus message informing them of the new message. These notification messages are encrypted with the Agreed Key of the two parties derived from a Diffie Hellman key exchange. 

The recipient's Chat application reads the shared container and his or her own chat container, merges them, sorts them by the message timestamp and displays them to the user

Chat messages are never stored locally and have the full security/privacy of the Murton Container technology to protect them. This I call 'Eye-to-eye Encryption'. The messages are only in the clear when displayed in a UI. This simplicity makes the prospect of very large chat groups less challenging than the Signal Protocol's because the complexity of 'per-message-encryption' is not required (Its 'per-container-encryption' instead).

​

Users can exchange documents using  the chat application. Each document is stored in its own encrypted container and the associated application for viewing the document can be launched from within DicePassword.

​

Documents can also be sent for signature by both parties and the chat environment provides a means to negotiate the content of each document with an audit trail of the negotiation as a permanent record. The audit trail also includes all previous versions of the signed document. The intention is to provide the basis for a workflow (in later versions) that provide 'Legal Certainty' and 'Evidential Weight' for professionals who need that.