Create a gist now

Instantly share code, notes, and snippets.

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.
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 (kpub) 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 (kS/HVN)pub that was previously shared during (1).
Using the Server/HVN (“S/HVN”) (kS/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 (kclient)pub) and a Tx_output to S/HVN address (a hashed (kS/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 (kclient)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 (kclient)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.
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment