Identity Control and Security Aspects of D-DDN™ & D-ISP™
D-DDN, and the D-ISP servers connected, provide a secure Distributed Data Network. Each D-ISP server in the network receives requests on a queue id group, forwarded by D-DDN through a network based on the NATS messaging protocol. The underlying data store is based on an entity-bound, patented, key/value document store with unique access control structure determined by allocated ‘relationships’ between the owner of the data (the target entity) and anyone requesting access to the data (a Relationship Distributed Identifier – RDID). Relationships may be approved by the target entity or can be by made by proxy in an application with proper credentials. Only by possession of a proper RDID can an entity access an entity’s data.
The particular queue id a D-ISP server listens to is determined from several factors for example geolocation of the entity for purposes of complying with privacy controls like GDPR. Additionally, queue ids can be allocated based upon enterprise constraints, or any other collection desired. The particular queue id to accept requests from is passed on the command line at server startup.
Roles
There is a hierarchy of defined roles which an entity may possess.
- System Administrator – ‘sysadm’. This entity has rights to perform all actions within the D-DDN. It is created at Data Store creation and cannot be duplicated. Its passcode, the ‘password’ required to login, is stored either on disk in the server startup directory, or, in extremely secure applications, in a TPM (Trusted Platform Module) controlled by the CPU. Only sysadm has permission to create the initial ‘genesis’ Administrator admin, from which all other entities are created.
- Administrator – ‘admin’. Created by the genesis admin with privileges to create administrators, domain administrators, and other entities. It has the ability to modify but not delete other admins.
- Domain Administrator – ‘domadm’. Created by an admin but restricted to creating developer and cohort entities. It can modify or delete entities it has created, but cannot create or delete other admins.
- Developer – ‘developer’. Created by admin or domadm. Developers can create cohort entities (entities registered with system). They can modify or delete entities they have created or may create another developer entity.
- Cohort – ‘cohort’. Any entity registered with the system. Cannot create any other entities.
Groups
Besides roles, entity credentials may be tied to group membership. Groups are specified by simple comma-separated list of group names. Group membership is checked when retrieving data. If the data access template (discussed below) specifies a group to which the entity does not belong, redactions on the data returned from a query will be performed. Group access can be programmatically checked by querying an entity’s profile.
Data Documents as Access Control
D-DDN offers a mechanism that provides for the ability to restrict resource access control through the storage and controlled access to data documents that define resource access. Rather than defining resource access as inputs from the mapping of a hierarchy of user credentials and roles, D-DDN controls individual resources by a one-to-one mapping from a resource entity and its data documents to the data access privileges of the requesting entity. Control is accomplished by creation of one-to-one Relationship Distributed Identifiers (RDIDs) between the resource entity and the entity using the resource. Without possession of a proper RDID, access to data documents, and therefore the policy statements held in those documents, is impossible.
There can be no acquisition of another user’s credentials. A RDID for one user is not usable by another. It cannot be reverse-engineered being composed from many hashes. And the pivoting so often used by hackers and ransomware to explore network resources is simply not possible.
Authentication
When an Entity (user, device, microservice, program, logical group, i.e., any nameable object) is registered (created), it, among other things, will be given a unique passcode which should be remembered or stored somewhere it can be retrieved. This passcode is a 64-bit hash of values which includes a random byte buffer. Therefore the passcode for one Entity will never be the same as for another. As a hash of randomized data, it is impossible to determine or guess the passcode of any entity. This passcode is stored in the profile of the entity and is checked upon each request of services. Registration of duplicate entity identities is not allowed. As the storage location (key) of the entity profile is a 128-bit hash of various values specific to the entity, it cannot be reverse-engineered to guess the key. All documents stored in the D-ISP Data Store are encrypted either by the system key or by a uniquely generated entity data key.
An entity wishing access to the system must request an entity-login passing the identity and passcode returned from the initial entity registration. This is checked against the entity profile, and if it passes, a JWT (JavaScript Web Token) and the server’s public key is returned. This JWT contains the base62 encoding of a server encrypted user and passcode, the expiration time of the JWT, the instance of the server issuing the JWT, and a refresh login value. From the initial login request on, a session public key is used to encrypt all responses from the server. The server’s public key is likewise used to encrypt all requests sent by the client. See the discussion below for more details. As only the client requesting login has the temporary uniquely generated private session key by which to decrypt the server’s response, capturing the JWT does not allow eavesdropping on traffic from the server as only the client instance that performed the login will have the private session key. Only garbage will result for all others. The server caches the session key to JWT relation. It is checked on each request and it will not respond to a request whose authentication doesn’t have a matching public session key.
Authorization
Authorization consists of two processes. First, D-ISP will apply access controls as above.
Second, access privileges can be configured by formatted documents stored in D-ISP whose access is determined by a RDID that configures what can be retrieved. A RDID is created by the resource entity or proxy (i.e., the privilege-checking-issuing program) giving access to only the requesting entity encoded in the RDID. RDIDs are an opaque byte buffer encoding the components and privileges of the relationship. RDIDs can be configured as read-only, where storage of entity data is not allowed, or as read-write. Without possession of the RDID and subsequent matching entity login, privileges will not be allowed for another entity, i.e., even if captured in a breach, the RDID will not be valid for another entity.
There is no mechanism by which to navigate or iterate over the set of entities in D-ISP. Access to any entity requires passing all parameters that make up the original storage location key calculation. There is no storage of the set of entities in D-ISP. This prevents the pivoting or acquiring another user’s resource credentials.
Auditing
Auditing of resource usage is accomplished by inspection of servers’ logs. It contains the parameters of every data access request. It contains the path, and therefore the storage location of the data. Included in the path are the RDID and components used to locate the data in storage. Also included in each request is the JWT of the requesting entity. If not validated an error will be entered in the log and the request will fail. Looking for these instances would provide knowledge of attempted hacks with the information of who and other parameters of the attacker.
Additionally, patterns of data storage and query may point to illicit operations of authorized entities. This might point to insider malfeasance and sharing of credentials.
D-DDN allows ‘locking the barn BEFORE the horse escapes’. Very different from available access control schemes that only attempt to find holes in your defense AFTER the horse has escaped.
Conclusions
We have shown how Dataparency’s D-DDN product can be the foundation of a network access control scheme. It can be used to design a complete distributed access control platform. It can provide a ‘3D’ control infrastructure where control is applied to deep levels of access, even within programs or resources. Whereas most platforms only provide ‘2D’ controls, at the network and program access level, D-DDN provides for control within the entire resource AND data space. And this control can be the foundation of a Zero Trust model, trust no one and verify always.