All posts by Dr. Michel Floyd
Business need to connect with other businesses to trade and add value. Making trading fast and efficient means integrating software systems. And that means risk.
Letters, faxes, and telegrams may seem slow and quaint but at least they had the virtue of being safe. In today’s environment clicking on an unsafe link or opening an innocuous file can potentially lead to a billion dollar loss or even the end of your company.
Following last year’s massive Target breach attention has moved to Wall Street; the JPMorgan breach is causing state and federal regulators to add to the already massive internal pressures to improve security. One particular area of attention is the risk that comes from 3rd party vendors.
New York State’s top financial regulator, Benjamin M. Lawsky, emphasized the gathering danger to the financial system when vendors’ security is lax.
There are several critical problems in dealing with 3rd party risk. The first one is that the risk exposure is hugely asymmetric in most cases: one party has much more to lose than the other. This leads to the second problem which is that the smaller party can’t afford to spend nearly as much as the larger one on cybersecurity. The skill of their security staff will be lower, they will have fewer tools at their disposal, they may even be too small to afford round-the-clock monitoring. They also probably cannot afford enough insurance to compensate their larger partner for losses.
The first instinct of the larger party is to seek to impose their internal security standards on the smaller party; the goal is to avoid the smaller party becoming the weak spot in the fortress wall. This has the effect of raising trading costs. If the smaller party is a vendor then that vendor will need to raise their prices to cover the extra security costs. At some level those costs may become prohibitive; at my previous company we ended up no-bidding certain RFPs because the attendant security overheads were too high relative to the deal size. The next thing to suffer is agility: vendors whose security has been certified become automatically preferred for future work because of the time and expense involved in certifying new vendors. This reinforces the upward pressure on prices as incumbents are protected from new competitors. Innovation suffers as well.
How can businesses integrate with their value chain without taking on untenable, asymmetric risks? The Cloak Labs Global Virtual Bus provides businesses with a way to loosely couple with their partners. Using a combination of cryptographic and network techniques, the Global Virtual Bus can insulate each partner from the security risks of the other. Credentials do not need to be exchanged, firewall ports do not need to be opened, connecting servers do not need public IP addresses.
Download the White Paper!
Recently Apple announced they have strengthened encryption on its mobile (IOS) devices to the point that it can no longer decrypt their contents on behalf of the government, even when presented with a valid search warrant. Google followed suit, announcing that Android devices would be encrypted by default.
On the heels of the unauthorized release of nude pictures of many celebrities, apparently purloined from iCloud with stolen/hacked credentials, many might see these moves as being strongly in the interest of consumers’ privacy.
The director of the FBI, James Comey, begged to differ. Attorney General Eric Holder followed suit. Both cited concerns about such encryption hindering criminal investigations.
The US government has been fighting strong cryptography for years. Cryptography has been classified as armaments and subject to export controls. The US (and the UK) benefitted strongly from a cryptographic advantage in World War II and through much of the cold war: the US could break its enemies’ cyphers but not vice-versa. In 1993 the NSA introduced the clipper chip and tried to make it a standard. This effort failed spectacularly as the market completely rejected a chip that contained a backdoor for the NSA.
Cloak Labs is committed to protecting data privacy. The very idea of a master key or a backdoor into a security system is anathema to those who are serious about security.
The security industry’s efforts to improve security were bolstered by Edward Snowden’s revelations about widespread NSA wiretapping activities in 2013. For example there are now a number of secure email systems (ex: Proton Mail).
I believe that what is really concerning the US government is the idea that encryption is moving from being something optional that is hard and error-prone to configure to something that is standard, default, and easy (specially given Apple’s focus on ease of use). Criminals might not bother to setup security or might set it up incorrectly. Now Apple and Google are protecting even the dumb criminals who are just buying phones at their local store.
By abusing their surveillance powers so egregiously for so many years the US government has lost significant goodwill with a large segment of the American public. Not only do consumers want to be protected from lawless hackers, many of them no longer trust their own government. Parallel reconstruction, where an intelligence agency that nominally targets foreign intelligence targets provides secret intelligence to domestic law enforcement agencies who then reconstruct it in order to make it admissible in court, makes a mockery of the rules of evidence.
It’s extremely unlikely that congress will pass legislation that requires companies such as Apple and Google to make it possible/easier for the government to access private information. If they did, it would cripple American products in global markets.
Device encryption will force the government to get a suspect to provide their password (or fingerprint) to unlock it to access evidence. In some cases the courts have held that a defendant cannot be compelled to provide a password since they might incriminate themself by doing so. In other cases the courts have compelled a defendant to reveal their password. This might make for an important Supreme Court case someday.
Not very long ago and not very far away, scientists, engineers, and possibly Al Gore, began inventing the fundamental building blocks of the Internet.
Development of the Internet from Arpanet to W3C (Internet Society Graphic)
During this period of accelerating invention, those making the important discoveries were primarily concerned with getting things to work. Few networks were connected together and those that were tended to have close relationships and a high degree of trust. A network inside a building or facility was secured by physical access. Password access to the local network was largely sufficient.
Security was always an afterthought
The hacker movement closely followed the development of the Internet
. In the 1970s many hackers amused themselves by hacking phone networks, so called phreaking
. One of the first large scale network hacks
was an attack on 60 institutions including Los Alamos Laboratory and the Sloan Kettering Cancer Institute. The first firewalls emerged in the late 1980s
as basic packet filters. It wasn’t until the 1990s that researchers begun working on layering security
on top of TCP/IP, the fundamental protocol of the network, which unfortunately happened to be fundamentally insecure (no encryption, no authentication of access points, etc…). DNS, the service that translates natural language names such as CloakLabs.com
into machine addresses such as 22.214.171.124, was also fundamentally insecure. Work on DNSSEC
didn’t start until 1990.
Enter Technical Debt
is a metaphor referring to the eventual consequences of poor system design, software architecture or software development. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on.
Technical debt is incurred in almost every software project of any complexity. There’s always a nagging bit that could have been done better, an interface that should have been exposed, test cases or documentation that should have been written. Projects incur technical debt because of lack of time, lack of resources, sloppiness, poor training, poor vision, and countless other reasons. However there’s little doubt that most projects would never ship if all the technical debt had to be paid beforehand. The Internet is not a single project, it is a mammoth collection of smaller projects, with the core projects having significant debt on the security side.
Move fast and break things. Unless you are breaking stuff, you are not moving fast enough. – Mark Zuckerberg
The entire internet security industry, including Cloak Labs, owes its very existence to the technical debt incurred by the designers of the Internet. Of course the Internet would still be under construction
if it had been required to be secure from the very beginning; you wouldn’t be reading this in a web browser or on a mobile device and you’d be wondering what to do with all the free time you would have had from not having to keep up with Facebook and Twitter. Those closely concerned with cyberwarfare have even advocated that we shouldn’t have an Internet
due to the high risks it creates for our modern infrastructure (power, water, financial services, transportation, healthcare, …) Have we amassed so much technical debt that our economy will eventually crash, not unlike what happened with mortgage debt in 2008? If you had been one of the inventors of the Internet, what would you have done differently knowing what you know now?
Security remains a top concern for IT managers considering the cloud. This is symptomatic of trust issues when working with cloud providers. After all, when you hand your precious data over to a cloud provider in general you are also handing over the keys! Just like when you valet your car. You’ve never met the young gentleman with the red vest and the bow tie but you are handing him the keys to your brand new Mercedes! Your corporate data could be worth much much more.
Once you’ve handed the valet the keys to your data you have no control over how he (she) handles those keys or who they might share them with. This applies to your data as well. The primary fear is that hackers might gain access to your data and exploit it, resulting in loss of your business reputation and real money. Cloud applications, even when they are encrypting data in the cloud, have the keys to your data somewhere. Exploiting the application may reveal the keys or the application might be altered into revealing your data.
Inadvertent release (leakage) is also a possibility. The application may have a bug or security hole that someone might stumble into. The application thinks you’re asking for your own data but the requestor is actually someone else. Such errors are unfortunately all too common.
Then there’s access by state actors. For data stored in the US, the US government has several legal tools available to get access to your data without you ever being informed. If you’ve given your keys to the valet, the feds present the right legal documents to the valet (subpoena, national security letter, sometimes even less) and the valet gives them your data. Recently a NY court held that the US also has legal authority to request data that is stored overseas! This brings new legal risks for data stored everywhere. Foreign authorities may start making requests for data stored in the US by US companies that have overseas subsidiaries. European efforts to keep data in-country may become moot if the providers have presence in other countries. While one of the key benefits of the cloud is to make location irrelevant if this NY judge’s decision is upheld there could be a significant legal downside. Companies will feel that if they hold data in their own data centers at least they will be informed when their data is being requested by authorities.
At Cloak Labs we don’t hold our customers’ private keys. Only the sender and recipient of a message can read its contents. We don’t have to ask you to trust our cloud infrastructure, encryption and decryption happens on your premises. Our cloud infrastructure just queues and transports encrypted messages. Were we to be subpoenaed for your data, we would of course legally be forced to cooperated, but all we could provide authorities with is highly encrypted messages. We don’t wear shiny red vests and bow ties and we don’t have the keys to your data.
We are pleased to announce that we are changing the name of our CloudPrime operating company to Cloak Labs. This name change is designed to better focus our brand on what we actually do: protect and secure your high value data.
Although the CloudPrime name is very straightforward, in practice it turned out that while many people correctly understood that the Cloud in CloudPrime meant we were a cloud-based company, the Prime didn’t immediately evoke prime numbers and cryptography. As a computer scientist might say, it was one level of indirection too far from obvious.
The Cloak in Cloak Labs refers to our first mission, which is security. We’re here to secure your messages from everyone except the intended recipient. That includes us: we don’t have the keys to your messages and we can’t decrypt them even though each one passes through our network (actually twice, for redundancy and reliability).
The Labs in Cloak Labs reflects who we are: computer scientists, security experts, engineers. We wear the lab cloaks so you don’t have to. Our job is to keep making our service more secure, more reliable, easier to use, more scalable, and more open.
In conjunction with the name change we’d also like to announce our new website:
In the near future when you visit CloudPrime.net you will automatically be redirected to CloakLabs.com.
The new Cloak Labs website includes a number of new pages describing our product. It also integrates our blog directly into our main webpage. This way visitors don’t have to deal with two different sites. The new site is also mobile-responsive and touch-compatible so you can visit on any phone or tablet as well as using your desktop or laptop – the information is the same from any device just presented in a way that best suits each device!
It’s going to take awhile to change our software itself to reflect the Cloak Labs brand but as we visit each module in our code to improve it we will do just that. In addition, customers should continue to use “CloudPrime” on checks until we update our billing processes.
Years ago a wise man told me that A “brand” is a promise made to its customers. It’s not just a name or a tag line. Our promise to you is that we will keep your messages secure and deliver them reliably; cost efficiently and with minimum effort on your part. By doing that we will also keep your enterprises more secure against ever increasing security threats.
If you’d like to keep up with the exciting things that are happening at Cloak Labs, please visit http://CloakLabs.com and read our blog at http://CloakLabs.com/blog We’ll also continue to update you occasionally via email as well; hopefully not too often!
Dr. Michel Floyd
CloudPrime Cloak Labs
This post is going to get a wee bit technical so bear with me. There is a well publicized HIPAA requirement that
PHI (protected health information) must be encrypted in motion and at rest.
This requirement has been interpreted to mean that:
- PHI transmitted over a network (or even carried via removable media) must be encrypted
- Data on disk must be encrypted
HHS documents often refer to NIST’s Guidelines on TLS. (TLS is what has replaced SSL except in normal discussion). What the current Heartbleed problem with OpenSSL lays bare for all to see is the gaping hole in what encryption in motion can mean.
The problem is that for the most part the encryption in motion is different than the encryption at rest. Different algorithms and keys are used and different systems have responsibility for crypto. Simply put, this requires the data to be unencrypted when moving from the network to the disk.
Cloak Labs’ technology allows a message to go from one server behind a firewall to another server behind a second firewall without exposing either server to the outside world. Inbound firewall ports don’t need to be opened on either side and the data stays encrypted in webserver RAM, essentially adding an extra barrier between your sensitive data and potential attackers.
This week’s revelations of the Heartbleed defect in OpenSSL has been eye opening for the entire Internet. Bruce Schneier labeled it “Catastrophic. On the scale of 1 to 10, this is an 11.”
The Snowden revelations raised our collective concerns for the security and privacy of the internet. Even those who attribute only noble intentions to the NSA realize that if the NSA can crack a code then perhaps less savory actors can as well.
SSL is something we’ve all taken for granted as something that just works to keep internet connections secure. As computers have gotten faster key lengths have increased. The SSL algorithm itself has been replaced by TLS but the old name has stuck around. SSL has been so useful and simple that it has been embedded into every browser, almost every VPN, and now even in thermostats and smart refrigerators. The Internet security community has figuratively put almost all their eggs in one basket. That metaphorical basket has just been dropped on the floor and now we have a cleanup on aisle 4 of epic proportions.
At Cloak Labs we have reviewed our production and development systems to make sure that we are not vulnerable. Our enterprise messaging system does not use the defective version of OpenSSL and was never at risk. We did have to patch one of our WordPress servers but that was about it.
But more importantly, Cloak Labs’ messaging technology provides defense in depth. Even if we had been running a defective version of OpenSSL the RSA and AES layers used to protect your messages would have not been compromised. The security provided by AES is second to none and Cloak Labs’ robust approach to PKI makes compromise of the RSA layer virtually impossible.
At Cloak Labs we enjoy using fortresses as visual metaphors for network security. In that vein, here’s SSL:
And here’s Cloak Labs:
Defense in Depth as Designed by Sébastien Le Prestre de Vauban
Vauban was one of the foremost military engineers of the 17th century. He mastered the concept of fortification in depth. I learned about him studying about the past glories of France in the French expat schools I attended as a child.
Which fortress would you rather be inside of?
Dr. Michel Floyd