Proof-of-Identity: Applying Basic Security Protocols

July 17, 2017

This is the complete Proof-of-Identity series. Each subject is 1300 characters or less. Security Protocols are not optional, here are the proper application of some critical security protocols.

The Series Index:

Access control must begin before the secure environment is encountered.
Two-factor security must be applied at both ends of communication.
Access Control requires authentication prior to learning the address of its Only-Known-User community.
Apply communications security throughout the process.
Nothing related to secure activity should be initialed from installed software, stored or cached to a local device.
One-size-fits-all access model for every type of data is invalid.
Use the proper access method to match the proper data class.
Basic security protocols applied to achieve physical presence access control.

Proof-of-Identity 1:

There is a simple explanation for cyber security failures, not requiring Proof-of-Identity as part of access control security protocols. It is not a technology problem but rather a choice not to apply proper technology for access control.

External breaches result from failures in security protocols to Only-Known-User environments. Access control protocols from the real world must be applied for the digital world. Security protocols are not a variable!

This is the first a “Proof-of-Identity” series: So let’s start at the beginning.

A secure environment is one in which only known individuals are granted access, while restricting access from unknown individuals, pretty straightforward.

In the real world, identification is checked prior to entry. No one gets into the White House without a verified ID or there is a breach.

In the digitally world unknown entities input data at a public website portal & submit it into a secure environment for authentication. This means unknown content from unknown entities gets INSIDE a secure environment before security is engaged.

Take-away 1: Access control must begin before the secure environment is encountered.

If unknown users have access to a secure environment’s portal, Proof-of-Identity has failed.

Proof-of-Identity 2:

When requesting access to secure environments in the real world there is a human being & identification present for authentication. In the digital world 2FA “proves” an individual is present to input data. However, at the secure environment there is only unknown data being presented & after authentication the token is no long needed, a nanosecond presence check.

In the real world a human body is a factor. A similar factor must be required for Proof-of-Presence digitally, a token. Properly deployed tokens are critical for access control. Presence at the Endpoint & data-only at the server is only half of a solution

A uniquely serialized token must be present at both the endpoint & the Only-Know-User environment. This proves that a specific token is present, a Presences-Factor. Any Data-Factor would be valid in conjunction with a presence-factor.

Take-away 2: Two-factor security must be applied at both ends of the communication.

Two-factors throughout the process can be accomplish with a token integrated operational environment. The token must be present or there is no method to access the environment. Sever security accepts only operation environment connection eliminating.

Proof-of-Identity 3:

Real world access to a safety deposit box requires physical presence & identification. The same is true to access funds. A properly deployed uniquely serialized token proves presence to a secure community. The token however must be pre-authenticated before connecting it to the secure environment because: “Access control must begin before the secure environment is encountered”.

The token must have no knowledge of its Only-Known-User community until after authenticated, a blind token until after authentication.

The token is connected to a device & the pristine environment is created from the token. The token authenticates, receives the address to its secure community, connects & loads the login process. The token, “something you have”, present throughout interaction with the secure community.

The token’s presence is required at Endpoint & the Only-Known-User community. If the token has been reported compromised the authentication servers send a self-destruct code disabling the token permanently. The off-site Authentication process assures only authenticated tokens learn the address of their Only-Known-User community.

Take-away 3: Access Control requires authentication prior to learning the address of its Only-Known-User community.

Proof-of-Identity 4:

Establishing proper access control protocols requiring two UNIQUE factors at the Endpoint & Server (Post #3) has been presented, next secure the communication process.

Not a technical description:

The token-based operational environment establishes a secure connection to the Authentication Server (AS) & maintains the connection throughout the secure interaction. The environment pings the AS at a set interval to maintain an active session. The authenticated operational environment receives the address of its Only-Known-User community.

The Only-Known-User community permits authenticated operational environment connections ONLY.

At the community’s proxy server, the token’s ID is validated. Then the proxy connects to the AS, verifies the token has been authenticated and the session is active. The session ID is returned & if there is a match the LOGON screen is loaded. The Proxy pings the AS at a set interval and if the session is interrupted at the AS the proxy terminates the connection.

The proxy and the local environment is also part of the triangulated communication monitoring process.

Take-away 4: Apply communications security throughout the process for ONLY-Known-User communities.

Proof-of-Identity 5:

Secure activity for Only-Known-User communities have only two valid entities with knowledge of a user’s activity, the user & the community owner.

Ignoring the compromised nature of every device connected to the Internet is foolish, just read the published data. Installed software, soft token, security cert or other stored processes on a device CANNOT be trusted. One-step further, any secure data/activity that is cached to the local device must also be considered compromised.

The token, previous covered, must contain RAM & be Read-Only. These two features play an important part in access control security protocols. The token-based operation environment provisions the token’s RAM and then maintains all activity outside the local device.

When the token is removed all the session data is eliminated from the local device. The Read-Only feature means that as soon as the connection to the local device ends the session data evaporates with no footprint.

Take-away 5: Nothing related to secure activity should be initialed from installed software, stored or cached to a local device.

This process assures that when a secure session ends the only record of activity is at the Only-Know-User community.

Proof-of-Identity 6:

Overcoming friction is required to accomplish anything! To cash a check an individual goes the bank, presents identification, turns over a check, gets cash & drives home. Friction from the moment the process started.

Using the Internet also requires friction beginning at opening a browser & entering a URL. It is time to stop BullS@#ting and accept that FRICTION has always been part of Internet activity. Instead let’s assess the appropriate level of friction for each activity. Convenient access for known users has proven convenient for hackers as well. This discussion has been ignored since the beginning of public Internet usage.

Standards were recommended but the “inconvenience” factor made it necessary to lower these standards in subsequent years. The search for LOWEST set of standards for compliance began. However ignoring BASIC security protocols has made these standards ineffective.

There are three basic levels of activity on the Internet. Each requires unique security & an access method that matches the proper security level is REQUIRED.

Take-Away 6: A one-size-fits-all access model for every type of data is invalid.

Proof-of-Identity 7:

Computer Scientists understood the need to properly classify data but failed to apply unique access control for each class. Internet activity falls into three security classes:

Browsing which is how the current Internet began. In fact Browsers were created to navigate the Internet with a “user-friendly” method, thus the name browser. Minimal security required. PUBLIC Access.

eCommerce & email are both public activities however they require security. Public activity that creates secure data can only rise to Classified. So long as public access remains there is no way to deploy secure level protocols. The current access model for this activity is as good as it gets. CLASSIFIED Access.

Internal corporate communications & access, financial institutions, law firms, medical facilities always require ONLY known user access. Therefore public access is a basic security violation. The token solution from this series is for ONLY known user data. SECURE Access.

Data class must also isolate data by security level. The commingled data from the current access model must also be addressed or no solution will be complete. The time has arrived for basic analysis & logic to be applied to access control.

Take-away 7: The proper access method must match the proper data class

Proof-of-Identity 8:

A Proof-of-Identity token must be device agnostic, install no software and use no installed software. The token must be serialized, hardened and Read-Only. It must contain RAM to maintain secure data, software to create a pristine environment every time and upon removing the token no footprint is left behind. The environment is backward compatible so existing browser-based operations transfer with minimal effort.

The token is authenticated off-site and then routed to an obfuscated secure environment. Every environment is independent. When secure interaction is complete, the token is removed and all session data evaporates. Remove the token during the session, the session implodes and all session data evaporates.

The process is completely invisible; a user plugs in the token, clicks on “Start” and enters credentials in the logon screen. It cannot get any easier to meet access control security protocols.

Arrange a Conversation