C. Van de Werken

Odd Passenger: Solving User Authentication via Artificial Intelligence, Pt. II

January 16, 2017Christian Van de Werken No Comments

—–BEGIN HASHED POST BLOCK—–

Part II: Networked Smart Contracts

Since the beginning of my winter break from Columbia SIPA, I’ve had the opportunity to do some fairly extensive dev work on some personal smart contract projects. Among my aims was exploring the possibility of networked smart contracts (“NSC”). By NSC, I am not referring simply to contracts with public function calls of their peers, but rather to contracts that make public function calls to other contracts on other chains.

Currently, contracts written in Solidity have external visibility, and function parameters can be declared so that they may be accessed externally by other contracts. Should a contract need to pull in a function that is defined elsewhere, it can do so by creating an EVM function call and have that brought over to the current contract that is being executed. This has obvious advantages as some contracts may be complex and require segmentation for organization, or more practically, to ensure that gas is spent in an efficient and easily-auditable manner.

An oversimplified call can be seen in the following example:

However, the downsides of this system is that contracts can only reference others if they are operating on the same blockchain, such as ethereum. For now, given the relative infancy of the technology, this isn’t a problem as smart contracts are comparatively simple relative to their physical counterparts, and don’t require massive computations or complex logic. This will eventually change as time progresses and blockchains are incorporated into and built by more industries.

The reason that this functionality should be implemented is due to this future adoption, as well as the high likelihood that proprietary chains will be built to handle different processes and solve different issues. While a number of companies and projects are attempting to lead the future of blockchain development and design what will be the eventual standards of blockchain, there isn’t mass adoption of one set (even though there is certainly heavy sway towards technologies such as ethereum). Over the past year, I’ve consulted on a number of different blockchain projects and have identified a common theme in my work: while everyone wants their own “chain” to satisfy the same requirements as their peers, several clients (and especially larger institutions) need some intercompatibility with their partners. If everyone is using different blockchains, we’ve accomplished little more than overcomplicating extant proven systems.

Eventually what I see happening is that the number of available and competing blockchain technologies will get smaller. Hobby projects will eventually get abandoned, some of the more innovative chains produced by smaller firms and startups will be acquired, and several institutional collaborative efforts (such as Hyperledger) will remain as the enterprise-class options. Further, I envision that multiple chains will still exist, and this is especially true in industries where larger organizations have a good argument for implementing their own proprietary versions of blockchains (such as the financial industry).

Going back to my original point, there is no current way for these various blockchains to talk to one another. One might argue that the security provided by decentralization obviates the need for multiple blockchain implementations, and that all data that might need to be transacted on a blockchain could be transacted on a single chain. There are obvious disincentives. For example, in a highly-regulated industry such as banking, financial institutions would need their own ledgers to ensure adherence to incredibly complex auditing requirements. Organizations that require exceptional security such as governments might need to run their data in-house with each agency maintaining their own chain. Instances even as simple as a separation between corporate sales and manufacturing departments might have a decent argument to maintain separate blockchains. If chains are implemented independently, we need to design protocols and standards for NSC to facilitate secure and reliable communication and connectivity between them.

It’s important that the blockchain community writ large makes two important policy decisions. First, the community needs to decide on a clear and defined set of standards to abide by in the development of various blockchains. This is difficult given that interested companies, project collaborations, and open source efforts are constantly expanding the limits and possibilities of the technology. Everyone is moving outward in various directions to be first-to-market with their respective inventions and improvements. However, those moving in substantially similar or even parallel directions need to agree on a set of structural standards to ensure that if both chains get adopted, there are commonalities between them. An example of this is the Bitcoin Improvement Proposal (“BIP”) process where standards for Bitcoin go through a lengthy path of submission, evaluation, and implementation.

Second, in these standards, the blockchain community needs to implement robust communication protocols for these chains to communicate with one another. Chains will eventually replace many legacy systems but will likely do so independently rather than cumulatively, and they will need to be capable of “smart” conversations with their counterparts. There will be an eventual need to have movement by and between chains, either in the generation of new contracts on other chains, or simultaneous execution of contract terms on chains implemented parallel to one another.

If blockchain truly is the future (which I firmly contend that it is), the community should also look ahead to future challenges for the technology. Regardless of how many chains will exist within the ecosystem, they will eventually need the ability to interact with each other to guarantee advanced functionality. Designing blockchain products that are completely isolated from one another may seem like good business practices today, and may help businesses realize significant market shares, but it will hinder the technology’s overall potential going forward.

If you have feedback on this idea, I’d love to hear it! I can be reached via cvdw@werken.com.

—–END HASHED POST BLOCK—–

Featured Image Credit: Gerd Altmann, “untitled”. Public Domain Work. Modified, Desaturated.

SHA256(e2df40019a65ead380eaf365016d0f7a-b9b179454f3348a9adfc187c57a9c6cff15e6436.zip)= 09055f5b819086ada38c6e20654df5c7eb28944d18491a7c966822adefea14e8

Odd Passenger: Solving User Authentication via Artificial Intelligence, Pt. I

January 16, 2017Christian Van de Werken No Comments

—–BEGIN HASHED POST BLOCK—–

Part I: An Argument For Enhanced Data Logging in Machine Learning

One of the discussions I’ve recently found myself regularly engaged in has been focused on the dichotomy of privacy and machine learning (“ML”). These two concepts have been related for several decades, however they haven’t occupied the same discussion until recently — especially with the emergence of mass market IoT, advanced predictive analytical models, and innovations in consumer tracking. Until the last few years, it was possible to maintain separation between privacy and envisioning a future vision for “smart life” automation because people’s individual lives weren’t mined to make models more sophisticated and efficient. Previously, recorded voice from smartphones wasn’t used for pattern analysis [1]. Text messages, emails, and search history wasn’t automatically skimmed to create composite pictures [2, 3] of pertinent routines and daily events. Privacy policies originally required information submissions to be opt-in rather than opt-out. This trend towards reduced privacy has yielded a related inverse reaction in the growth and capacity of machine learning.

Before I begin this multi-part post, I want to note that I’m not an advocate for a reduction in privacy — quite the opposite actually. I believe in maintaining privacy on the internet and in devices that I use to access it. I believe in strong end-to-end crypto and security of communications technologies. I further believe in getting the opportunity to enjoy abstraction from data that I generate.

That being said, I’m also a strong proponent for improvements to and innovations of machine learning, especially as it pertains to the possibility of truly independent and functional artificial intelligence (“AI”). I believe that ML will eventually lead to robust AI, and that the collection of some data inherently advances this goal.

Unfortunately, these two concepts are paradoxically intertwined. It is not possible to simultaneously have explosive growth in machine learning and complete privacy. Devices need to thoroughly understand and interact with user data in order to expand the abilities of ML. However, to do so requires a reduction in the overall state of privacy protections that we enjoy today because these devices will need to learn about us to become better at working for us. Regardless of whether it is an organization or a singular device looking at data to analyze it, at some extent privacy is being scaled back in order to enable some type of function or benefit. We haven’t yet reached a balancing point between the two that affords adequate protection while enabling and incentivizing innovation. Organizations, industries, and governments are interspersed through the privacy spectrum and many today find themselves positioned at the extremes. However the only viable option to achieve the future of both is to remain somewhere near the center today.

It is important for the evolution of ML that we step back from absolute privacy and consider the possibility of living in a majority-private society. In such, devices and systems are allowed to learn about us in an independent and general sense, but not report back specifics that can be used to individually target us. This is not an argument for backdoors, increased surveillance, or the erosion of privacy protections, but rather an argument for a posture that increases innovation with relatively fledgling technologies such as AI. In order for artificial intelligence to move into the next phase of its evolution, the consumer population needs to become more comfortable with sharing some information with systems designed to analyze it. This has largely already occurred given the massive adoption of services like Google Maps (which uses satellites and cell towers to geolocate devices), Amazon Alexa (which listens to those talking within the vicinity of the device and relays speech to servers such as Lex to process [4]), among countless others. When I think of the long-term possibilities achievable by AI, I firmly believe they outweigh a brief and relatively superficial fluctuation in privacy frameworks.

This brings me to my main focus of this series: incentivizing the evolution of artificial intelligence to power the still-flawed problem of digital authentication.

We currently live at a time where identity and user authentication are inherently flawed. For someone to access a system or device, they must prove their identity or otherwise undergo some process to authenticate themselves. The most common mechanism is a password, although there have been notable improvements over the past several years to include keystroke biometrics [5, 6], wearables [7], among others. Unfortunately, all of these solutions still place the burden of identification onto the most insecure part of the process, the user. Passwords can be reused or insecurely created, wearables can be used without the user’s consent, and some types of biometrics can be forged. For each of these solutions, it is always up to the user to maintain the integrity, security, and possession of their authentication mediums. For most users, this is simply not practical as the sheer number of instances requiring different forms of access is too large to manage.

I contend that authentication of the future should not rely on users at all, but rather should be based off of artificial intelligence. Rather than continually try to improve inferior authentication mechanisms, there should be an effort towards developing completely secure systems that are aware of their users and know when and where to authenticate them. These systems would know enough about their users to grant them access to the same types of mediums where passwords generally suffice today. This is a realistic possibility over the next several decades if we transition as a society along the privacy spectrum to allow for the evolution of artificial intelligence.

Over the next few posts, I want to explore the possibility of creating AI authentication mechanisms, a project that I’ve codenamed here as Odd Passenger, and will from time to time refer to as Authentication by AI (“AAI”). I plan to identify and evaluate the technologies that I find pertinent to the concept, and present an idea that will hopefully turn into a future viable solution.

If you have feedback on this idea, I’d love to hear it! I can be reached via cvdw@werken.com.

—–END HASHED POST BLOCK—–

Featured Image Credit: Gerd Altmann, “untitled”. Public Domain Work. Modified, Desaturated.

SHA256(cb05ac6f578f97f14113553cfe5e990a-74e844ede81bdb75dbac0596c14a3db7fc1d1ba4.zip)= 06ae1a7b60bffa18f5d4f0e716e811ff91e26a827fdb924367ad95fa3edab15a

Nominal-knowledge Data Manipulation, Multi-state Cryptography, and the Clay-Balloon Analogy

November 23, 2016Christian Van de Werken No Comments

—–BEGIN HASHED POST BLOCK—–

Now that my deluge of midterms has subsided, the Inaugural #NYCyber912 which I co-organized is over, and my work as a SysAd successfully mitigated incursions into SIPA DCG’s infrastructure, I can now get back to my normal life. This means I can start thinking in the abstract again–at least until finals roll around.

Let me begin by presenting an analogy. Assume for a moment that you have a ball of pliable clay. Now envision that this mass is inside of an elastic balloon which is inflated. There is a small layer of air between the clay internals and the exterior material–just enough that the balloon obstructs what it encases. It’s possible to push on the outside of the balloon to work with the clay inside, but impossible to see its color, texture, shape, or other superficial attributes. It’s also possible to know that the clay exists, but not observe any of the resultant visual characteristics once the clay has been reshaped.

Recently I’ve been thinking about nominal-knowledge datasets–collections of information that can be aggregated without the collector knowing what the dataset contains. This is not a new concept as it exists prevalently in the world around us. Surveys are an easy example; a user submits information and assumes that other users are also submitting similar inputs (within the bounds of what is requested), but the user isn’t exactly sure what the database contains.

What is a novel concept is the continual ability of the user (herein, the “worker”) to work with and change what’s contained in the dataset without having read access to it (nominal-knowledge data manipulation, “NKDM”). I derive part of this concept of nominal-knowledge datasets from views introduced in 1985 by Goldwasser, Micali, and Rackoff on “The Knowledge Complexity of Interactive-proof Systems”. These authors originally introduced the concept of zero-knowledge and zero-knowledge proofs.

However, nominal-knowledge is not to be confused with zero-knowledge as “[a]n interactive proof is said to be zero-knowledge (ZK) if it yields nothing beyond the validity of the assertion being proved” (Rosen 2006). In the case of nominal-knowledge, the worker has some understanding of what the underlying data happens to be (hence, not zero-knowledge).

Zero-knowledge proofs (“ZKP”) work by having those that own or maintain information prove they are the only legitimate ones with access to it. By comparison, NKDM works by giving the worker only enough access and information about the dataset so that they are able to consistently work with and help maintain it. However, NKDM does not give the workers enough information to know anything substantive about the effects of their inputs, calculations, or edits. Rather than proving that communications between untrusted parties is authentic and legitimate (ZKP), NKDM allows for workers to affect the data without being privy to all of its attributes (the clay-balloon analogy).

For clarity within this post, the term “user” will be referred to hereinafter as “worker”. This is to distinguish between workers (who work with data) and owners (who own and maintain the data). This is also to avoid conflation with users that are included in the “other” permission group in “owner-group-other” unix file permissions.

The importance of this concept relies not on the cryptographic assurances that data is authentic, but rather that the data is abstracted from those that have access to it.

Obviously, this is a wildly theoretical concept, and one that seems more at place in quantum computing rather than in binary digital computing.

NKDM is a more realistic quantum concept because the data would have to exist in different states simultaneously (a ball of clay and an obstructed ball of clay). Data would have to exist in plaintext for the owner of the data, but would also have to exist in a separate (and encrypted) state for the worker. Ignoring the obvious public key/quantum issues for a moment, it’s easy to explain NKDM in terms of public key crypto. The owner would have to maintain the data as its prime factors, but each time the data was accessed by the worker, it would have to be presented to them to work with as very large non-prime integer. Once the data was accessed and manipulated, it would have to exist as a resultant large non-prime integer, but be capable of being simultaneously factored by the owner to a new set of prime factors respective of the worker’s manipulation.

To some extent, this concept is already feasible in traditional binary digital systems. In unix-based environments for example, a file can have permissions set as -rwx-w---- (where the “worker” from this example takes the place of the “group” in unix file permissions). However, the group would have to know what the file looks like initially so that it could make changes to it. This does not derive the nominal-knowledge benefits that the multi-state crypto (“MSC”) provides in NKDM (MSC being the disposition of the data to exist in different encrypted states at the same time). The group gets no feedback on how the data is manipulated, it just simply knows that it changed because of its actions. One errant edit can ruin the integrity of the entire dataset.

Unlike in traditional systems, workers in NKDM environments know that the data exists, how it is changed, and what other options they have available to work with it. Using the clay-balloon analogy, the worker knows that the clay has been manipulated, it just doesn’t know the full extent of its new shape or the composition of the clay. Put another way, in NKDM the worker gets some sense of how its changes interact with the data, just not what the comprehensive results happen to be. The benefit here (in addition to information security), is that the data maintains its integrity. Because the worker is getting some type of feedback from the MSC data, it knows whether its edits are useful or detrimental to the data’s overall state (e.g. did the clay break apart into multiple pieces after the last change?).

There are numerous benefits to NKDM, but the most important are in the financial, health, telecommunications, cloud computing, and defense & intelligence sectors.

Finance and Health: Audit Trails and Access Control. NKDM has a place in the financial and health sectors because it allows for efficient and absolute PCI, SOX, GLBA, and HIPAA compliance, among others, because the data is dynamic but readable only to those that require access. With this innovation, it would be possible to set specific and independent access controls on the data for individual machines like medical devices, and entities like technicians, administrators, and insurance companies.
Cloud Computing: Microtransactions and Pay-per-compute Instances. NKDM could revolutionize how server farms, supercomputers, and academic institutions handle computational tasks for customers. Rather than giving services like Amazon AWS or Google Cloud Platform complete access to data, it would be possible to give them access to abstracted data and let their hourly compute instances work on conducting nominal-knowledge calculations rather than calculations on plaintext datasets. In essence, they would be processing computations, they just wouldn’t know what they are computing.
Defense and Intelligence: Reporting and Analysis. NKDM has the ability to add a layer of abstraction between those involved with reports and those involved with analysis. Regardless of organizational policy regarding whom should have access to finalized reports, NKDM adds a layer of security to reports drafted abroad in enemy territory. Even in the event that a field post is compromised, security of the reports is maintained because the operator in this environment didn’t have read access to it in the first place.
Telecommunications: In-transit comms. NKDM could also be used to manipulate and/or evaluate encrypted data as it’s in transit. For example, it could adjust the level of compression of individual files to facilitate faster transport of end-to-end encrypted communications. Alternatively, NKDM could evaluate the actual use of data that is transported over dedicated connections to dynamically adjust how much customers pay (based on what’s used and not what’s allocated). Obviously there are also defense and intelligence applications here as well.

There are other instances where NKDM could be useful–basically any application where access control is paramount and where dissemination must be limited. Essentially, any instance where data needs to be dynamic/updatable and simultaneously secret would benefit from this concept.

Unfortunately, to reiterate, NKDM is not possible given current advancements in computing. Until quantum becomes standard, the world will have to make due with relying predominantly on the judgement of humans rather than strong crypto to protect information assets. In the interim, it’s fun to ponder unprecedented new ideas such as NKDM and consider what cybersecurity will look like in the future.

—–END HASHED POST BLOCK—–

Featured Image Credit: David Bleasdale, “letter-sphere-d”. Creative Commons Attribution 2.0 Generic. Modified, Desaturated.

SHA256(138ebbbc502332aa3a7ddc55bb94c810-1528bc7e666098b30986db25799fc6772bcdc271.zip)= dfddd96a8eab4413a6384908d73d84e5a79585068c59e0c7e1740375e8cd22ba

Codename Brazilian Mango: An Ad Hoc, On-demand, Pre-authenticated Dynamic Routing System

October 7, 2016Christian Van de Werken No Comments

brazilian_mango

—–BEGIN HASHED POST BLOCK—–

It’s astonishing what a midnight cab ride through New York City can do for creativity and imagination.

A few nights ago, on my way back from having dinner with friends, I was casually reading reddit in the back of a taxi. One of the links that caught my eye was by HACKREAD, “South Korea says their military cyber command was hacked”. Upon review, I clicked a bit farther to the source, Yonhap, South Korea’s largest news agency. A representative of the Korean government mentioned that “[a] malicious code [was] identified and it seems to have taken advantage of the vulnerability of the routing server”.

Although hacks that target routing mechanisms are certainly not unusual (as we have very clearly seen as recently as this past August), we should nonetheless continue to build better alternatives that mitigate their viability.

I started thinking about potential ways to address this problem more generally. Certainly, the easiest answer is to keep security products and perimeter defenses constantly updated to guard against known vulns. Additionally, having a team alert and ready to monitor logs and respond to incidents (especially in systems as critical as the South Korean Military Cyber Command) is crucial.

However, I was curious if there was a way to sidestep this problem entirely. I was trying to conceive a truly out of the box answer and I think I may have one. As with my inaugural post, I’d like to tack on the disclaimer that everyone knows me as “that blockchain guy” and that I typically think about solutions to cyber issues in terms of blockchains (“BC”). This idea is no different. I’d also like to note that I’m not a network guy – although I have some familiarity with terms and protocols, it’s definitely not my area.

Introducing Brazilian Mango

I’d like to introduce you to a [very cursory] new concept, Brazilian Mango (“BM”), an Ad Hoc, On-demand, and Pre-authenticated Dynamic Routing System (“DRS”) for Secure, High-value Networks. Brazilian Mango addresses the following two questions:

If high-value systems must be public-facing and accessible over the internet, why must the destination addresses always be reachable?
Wouldn’t a target that isn’t there be preferable to a strong target which everyone knows how to locate?

Admittedly, question two seems excessively theoretical, but certainly not without possibility.

A fundamental weakness of current routing systems is that the destinations must always be in a resolvable state to facilitate connection requests and then serve up content or run some type of service. Even if these systems are well defended, happen to be situated behind strong firewalls, employ sophisticated intrusion detection mechanisms, and have safeguards in place in the event that an attacker does break through, they’re still always reachable.

Now, obviously it’s possible to lock down networks in a manner where they only respond to connection requests from certain IPs they recognize (say for example, devices that facilitate interbank wire transfers, or ICS/SCADAs that allow remote access by devices connected via VPN and assigned an internal IP). However, if these networks are public facing and statically addressed, given enough time, intruders can plausibly work out ways to bypass or overwhelm these measures (such as through spoofing or through a DOS/DDOS attack).

Brazilian Mango mitigates these issues by keeping these high-value destination networks unreachable until such time as a trusted client is interested in establishing a connection.

A Nod to the Potential Shortcomings

At this moment, some may argue that this solution is prone to the same caveats as those mentioned above since at some point in the Brazilian Mango process, servers and networks are reachable. With BM however, this is addressed by pre-agreed upon shared ‘secrets’ that permit only pre-authenticated devices to connect, but in a dynamic manner. These secrets, in the context of exceptionally high-value systems, are relatively easy to prearrange (see Step 1, below).

Some may also contend that the concept is similar to services such as Cloudflare. However there are three important distinctions.

First, the destination addresses are kept undisclosed or are locked down to accept connection requests only from trusted clients (in this case, Brazilian Mango in Step 4a.1 below). Rather than being able to pass along a connection request to a service such as Cloudflare for routing to an endpoint, the request instead gets announced to Brazilian Mango for routing. If a destination server chooses to accept the connection, then it makes the opportunity available.
- BM has an alternative to this in Step (4b.1) below wherein no active connections are permitted, and instead the Server (or, as defined below, HVN) monitors the BM BC to generate new network security policy as necessary.
Second, destination addresses can change quickly and on an ad hoc basis. One of the main aspects of BM is that destination servers maintain a large pool of available IPs (perhaps ones that they trade in a clearinghouse with other organizations that use BM so that IPs are not routinely reused by the same entities). Think AWS Elastic IPs.
Third, destination addresses are only online for the duration that staying in a resolvable state is necessary, otherwise they remain uncontactable.

impatient_dog

The Impatient Dog Analogy

Before I get increasingly technical, I offer up “The Impatient Dog Analogy” as a simplified alternative. Obviously I would prefer you read on through the “Steps of the Brazilian Mango DRS Process”, but this is a 10k foot view looking at the fundamentals of the process.

I liken this concept to a dog, who we’ll call Molly, that is outside on a porch next to a door. The owner of the dog is inside sitting on the couch not paying attention to their pet. The owner wants to allow Molly in, but only when they know that she is actually waiting outside. Keeping the door constantly open will enable any one of the members of the family of raccoons that has taken refuge in the nearby forest to enter at will. The owner thus waits for Molly to announce their presence and desire to be let in by listening for a familiar bark. Once the owner hears Molly’s request, they will get up and open the door for her. Unfortunately for the raccoons however (all whom are unable to replicate Molly’s sound), they cannot indicate their presence and desire to enter the house. Molly has an added benefit: the house has multiple doors that the owner is willing to open, barking at any of them will get the owner’s attention and she will be let in. Unfortunately for the family of raccoons however, doing anything other than barking in the same manner as the dog at any of the doors will not induce the owner to open the door.

Steps of the Brazilian Mango DRS Process

The Client and Server (and/or High-value Network, “HVN”) exchange their public keys (k_pub) with each other (likely through a physical exchange). Much like with specialized military communications equipment, devices must initially be in the same place or must at least have an initial, absolutely known-secure transfer medium to coordinate the sharing and/or pre-arrangement of ciphers.
At some time in the future, Client makes a request for connection using the Server/HVN’s (k^S/HVN)_pub that was previously shared during (1).
- Using the Server/HVN (“S/HVN”) (k^S/HVN)_pub, the client encrypts its current public IP address along with other parameters in the connection request (such as preferred connection duration, expected bandwidth usage, etc).
Client broadcasts encrypted request to the Brazilian Mango network. This request publically shows a Tx_input from Client address (a hashed Client (k^client)_pub) and a Tx_output to S/HVN address (a hashed (k^S/HVN)_pub). Once this request is broadcast, nodes will propagate the connection request throughout the network. Presuming a valid request (see 4a.1 and 4b.1 below), the network will confirm the request, thus signifying to the Destination Server and/or Network that there is a potential connection waiting to be fulfilled.
Infrastructure Type Determines Step Four
- 4a.1 If BC is Ethereum-based (or an Ethereum-derivative), Autonomous Agents accept request, check for specific criteria, and route request to the Destination (the S/HVN).
- 4b.1 If Brazilian Mango is not an Ethereum-based BC (or a derivative thereof), the S/HVN will consistently and recursively scan the BC for any confirmed connection requests transacted on the network and sent to the Destination address (the specified Tx_output in Brazilian Mango).
  - The S/HVN may also maintain a local copy of the BC to verify transactions independently and maintain an audit log of both fulfilled and unfulfilled connection requests (See 6).
- 4a.2 & 4b.2 S/HVN receives request and decrypts it for connection info (assuming it matches criteria set by the Admin of the Destination or the team ensuring 4b.2 the security policy of the network).
S/HVN amends security policy, and assigns a Public IP to a gateway that acts as an intermediary between the Client/Server and/or Client/Network, that accepts connections only from the Public IP listed in the initial encrypted connection request from the Client (the confirmed transaction on the BM blockchain). This IP acts as a unique (to the Client) gateway into the remote network and is assigned from a pool of IPs that the network maintains for Brazilian Mango connections (that can be traded via clearinghouse as mentioned earlier). Client can request, and S/HVN can grant via BC scripting several parameters (similar to Bitcoin’s nLastTime, and OP_CHECKLOCKTIMEVERIFY) that invalidate certain security policies and specific connections at, before, or after a certain amount of time. The routing information is encrypted using the Client (k^client)_pub that was previously exchanged during (1).
S/HVN broadcasts acceptance of the connection request in encrypted form (See 5) to the BM nodes for confirmation and consequent addition to the BC. This indicates that the Client may communicate with the Server/Network using an IP (assigned to the Server/Network gateway), encrypted with the Client (k^client)_pub, and returned in the connection response. This step is similar to (3), only the response is transacted backwards — from the Tx_output address to the Tx_input address.
Client parses the BM blockchain to search for the response and decrypts the response to receive the individual IP assigned to it for connection with the Destination S/HVN.
Client and S/HVN communicate using the IP allocated for the connection by Brazilian Mango. In-transit communications can be encrypted using standard and commonly accepted methods to secure packets/connection during the session. Routing protocols such as TLS, IPSec, OpenVPN, and SSH, among others can be used to facilitate communication as necessary. These communications, once routing has been facilitated by stages (1) through (7) take place independent of BM as destinations have now been identified to the Client and the S/HVN, and both parties are made aware of where to route their secure sessions.
- At this stage, BM has now fulfilled two separate functions: first, it has securely helped coordinate potential connections, and second, it has replaced conventional authentication servers that are used in extremely-secure implementations.

A Note on Path Vectoring and Associated Protocols

Before I approach the analysis of the above process, I want to touch on the relationship of BM to current routing protocols. Brazilian Mango works predominantly at the application layer, and it’s merely a way of announcing and coordinating connections rather than facilitating them. This idea is not meant as a protocol to replace current path vectoring options like BGP or OSPF (among others) because it simply informs clients of which IPs they need to eventually route to. Instead, BM acts as a hybrid tool that complements current path vectoring. BM also ensures that routes that are authenticatable and ensured to be secure as the address is only known by the respective endpoints. Once IP information is exchanged by BM Steps (5 – 6), then protocols such as BGP, OSPF, among other link state routing protocols can take over to facilitate the connections.

That being said, Brazilian Mango is not meant to be a replacement for DNS either. The amount of applications that take place by DNS far outnumber the amount of potential applications that are composite to BM. This is specifically due to the fact that Brazilian Mango is a slow way of connecting secure S/HVNs with their users rather than a quick way of connecting users to both secure and non-secure destinations.

Analysis

This concept is certainly in its infancy. One notable drawback is the lengthy period of time in which it would take to make a request for a connection, have the destination S/HVN authenticate it, and open up the gateway for the Client to communicate with the S/HVN. Even with a block confirmation time of less than 60 seconds, this is still far slower than most other alternatives to remotely accessing a secure network (for example, just using a conventional VPN). Obviously this means that if it were to move past being a theoretical and onto the design and implementation stages, the service would be best for secure connections that don’t need to be immediately resolved but need to remain secure and whose existence would benefit from some secrecy and obscurity.

On the other hand, there are quite a few benefits to this method of connection. Rather than remaining operational and waiting for connections to resolve, thus leaving oneself open as a target, connections can be specifically tailored depending upon what the users and the network need.

Further, using a blockchain-backed access request log provides a concretely secure audit trail of connections (and alternatively, attacks). If something like Brazilian Mango existed and were maintained agency-wide, company-wide, and/or organizationally (or, less likely though even more compelling, industrially) it would be pretty hard to lose faith in logged access history since it would be maintained by so many different nodes.

Additionally, this type of blockchain does not suffer from the same issues as other BCs, such as those used for cryptocurrencies. Brazilian Mango is not hindered by size limitations and scalability issues because BM doesn’t have to maintain records of all unspent Tx_outputs. There is little likelihood that networks that use BM will need to keep IPs in a resolvable yet unconnected state for Clients a far time into the future. In these particular instances, the Clients can simply make a new request. After a certain period of time where a S/HVN approves a connection request that remains unfulfilled by a Client, it is advisable for the S/HVN to invalidate the unique IP from (5) above for security reasons. As such, the size of the Brazilian Mango BC only needs to be as large (and records need to be kept only as long) as the number of open sessions. Once the oldest open or authenticatable session expires, BM can dispose of any blocks prior and up to the block height where all connections are expired. Though, notably, some S/HVNs may keep the entire BC to ensure a sufficient audit trail of connections.

Finally, and most importantly, Brazilian Mango provides a new way of approaching access that doesn’t explicitly require cross pollination between systems. Put another way, requests for connections are abstracted from devices, and there isn’t a direct exchange between the connection requester (the Client), and the connection permitter (the Destination S/HVN). All of the data indicating how to facilitate communication is housed on a blockchain, in a size-enforced and encrypted set of request/response pairs. In short, there is very little likelihood that anything malicious would be passed along this venue that could potentially harm the Destination S/HVN before a secure connection could be established — unlike if an infected or malicious computer were to request access directly from an authentication server. Tackling this from an analogous perspective again, this is largely due to the fact that BM acts mainly as a town square where salesmen can yell to a large crowd that there is something for sale for particular individuals. However, these interested people don’t need to identified in the crowd to the salesmen for the message to be effective, and they don’t need to directly converse with the salesmen.

If you have feedback on this idea, I’d love to hear it! I can be reached via cvdw@werken.com.

—–END HASHED POST BLOCK—–

Featured Image Credit: Mark Hillary, “Mangas”. Creative Commons Attribution 2.0 Generic. Modified, Desaturated.

Secondary Image Credit: Germán Poo-Caamaño, “Almendra y su curiosidad”. Creative Commons Attribution 2.0 Generic. Modified, Desaturated.

Diagram Clipart: Openclipart.org

SHA256(4b32d0b9125cd9e8a09986677b878343-8b20da5188e11f235a7f81d7054a0e51adf2d243.zip)= fd6d0199cf917d79eb52ab6fb78c52ce1c031240a5af1a5597d9320f7d52a366

Authenticity > Identity

September 19, 2016Christian Van de Werken No Comments

authenticity-identity-14317072958_96dddfb620_o-bw

—–BEGIN HASHED POST BLOCK—–

I attended a dinner last night where the principal topics of conversation were cyber risk and cyber risk metrics that evaluate one’s own cyber impact relative to the rest of the global ecosystem.

One of the questions presented was, in paraphrase, “what is the biggest cyber threat that exists today”? I was expecting the usual trite response. I anticipated ‘advanced cyber weapons’, ‘APTs’, ‘hacks by nation states’, ‘metamorphic malware’, ‘information leakages’, or ‘organized hacking collectives’, and was caught off guard by the answer proposed: spam. I recognize there is a possibility that my MPA in International Security Policy has just made me a bit too security-inclined.

Out of the plethora of choices, spam was considered to be one of the biggest cyber threats today as it adds clutter to an already noisy environment. I would wager that this threat is considered dangerous less due to its [relatively minimal] propensity for tangible damage and more due to its innocuous state. Expectation and familiarity of conventional cyber threats causes a relative downplay of the real issues that spam causes. A significant amount of people expect a hack from Russia (and anticipate the ability of the United States to respond proportionally), but so many people expect to receive spam that they’re deadened to the reality of it.

The answer, “spam” was so shocking to me that I was curious if there was a better approach to eradicating it then we’ve seen previously. That made me think about blockchain solutions to the problem. Obviously I don’t purport my idea to be better than the rest (especially since alternatives have been tried for decades), but I do think it’s time for a shift in the status quo. Perhaps attacking the issue foundationally would be more effective than tackling it defensively.

What if you could cut through the noise caused by spam not by attacking the issue itself, but by redefining the landscape in which it exists? I think this solution manages to address this transformation.

authenticity-identity-4f5564b32cd5ca5d626ef281468cc063-bw

This is a transformational paradigm shift. If emphasis and value is placed on the items themselves (in this case, email communications), rather than on where they’re coming from, then it’s possible to unburden ourselves from spam.

Perhaps now would be an appropriate time for a disclaimer. Friends and colleagues know me as “that blockchain guy”. Admittedly a lot, if not an excessive amount, of my technical conversations manage to involve blockchains and/or cryptocurrency in some form or another. However, I do greatly enjoy thinking about the world’s problems in terms of these innovations. They’re robust, exceptionally dynamic, and groundbreakingly tailorable.

Getting back to the spam issue, let’s consider a solution to this problem by taking origin and identity out of the equation. This can be achieved by a concept that I’ve codenamed Slate Hawkeye (I give codenames to my own inventions simply so that they’re easier for me to reference in the future).

Slate Hawkeye works by maintaining a blockchain of the hashed contents of emails that are submitted by users (or via their mail clients). End user clients, mail servers, and recipient systems can be setup to only approve emails that match a particular hash, pattern, or those that are transacted on (read: submitted to) the blockchain by a certain k_priv. Spammers or malicious users are disincentivized by utilizing this system as it would be too resource heavy to submit hashes to the blockchain for large numbers of recipients, and it would be too costly from a resource standpoint to justify the transactional costs.

As with most of my work, I think this is explained better visually – please see the following diagram.

20160928_authentication_identity_concept

In this concept, authenticity comes from access control. Those that have the ability to transact on the blockchain, or in another usage, those that are willing to expend the resources to transact on the blockchain are the ones that have the ability to communicate. In the above example, the ability to do (3) can be done via a secure web app (a user requests access to be able to send a message). Alternatively, (3) can be built into an internal network, thus ensuring that only trusted machines are able to send messages (this would work well for incredibly secure networks where the ability to guard against spoofing is crucial). In either instance, this places the value of a message on the authentication stage rather than where it came from. This authentication medium is made possible by a multitude of factors, such as access management, and supported by expensive, and irrevocable or nearly irrevocable access.

One important issue to note is that this would be a lot slower than email as it is presently situated and would also be more computationally intensive – because of the need for the emails to be hashed. The hashes at least maintain anonymity of senders and security of the message as it’s not posted as plaintext, but it requires the client to hash the contents of the message, transact it along the decentralized ledger, and also requires the recipient to verify that the hash of the email they received is the same as the hash as submitted to the rest of the network via the blockchain.

Although there have been many other designs and implementations for blockchain-backed communications systems this is the first that both addresses the trust issue and the opportunity to counter nefarious adaptations of current systems. Perhaps the best implementation only exists in circumstances where authenticity of the message is imperative or security of the communications infrastructure has to be ensured. Since this is just a preliminary concept, I haven’t thought exhaustively about which hash functions would be the most appropriate for this adaptation, but I think that this would be a fun side project in the future.

—–END HASHED POST BLOCK—–

Featured Image Credit: Markus Spiske, “Nosy People”.

Secondary Image Credit: Netflix, House of Cards.

Diagram Clipart: Openclipart.org

SHA256(10adcc1c5e64fe47d02359070f2e4ae3-4e11febdf48956346491c5fd19b7185283f61147.zip)= 4986561ae2145093a3c7aa588b9d88f0ff1d51c1467a2ca13ec0f99107a7e8aa