The Market Ticker
Commentary on The Capital Markets- Category [Technology]

Public cloud computing, that is, computers at a remote location you do not own but lease space on, which have a hypervisor and clients running under it where you do not have complete, 100% control of said hypervisor are not secure.

If you have allegedly "encrypted" data there that is accessed, modified and used on said machine then the key to decrypt said data must also be on the machine and unprotected so it can be used.  If that is the case it can be trivially stolen since the hypervisor has complete access to all of the memory and disk resources of the client process and once stolen any pretense of security vanishes like a fart in the wind.

This is the lesson of the Wikileaks "Podesta" and related hacks.  It is not that Russia was involved (or not), it is not whether the "hack" was criminal, it is nothing of the sort.  It is that many of these people had their data (email in this case) on a public cloud environment and said environment was trivially broken into and the data stolen within minutes of being targeted.

The media and "business channels" have not and will not talk about this underlying fact for the simple reason that a huge percentage of the current market bubble is being driven and sustained by these so-called "innovations" and what they've done to market valuation.

This is continually claimed to be the "future" of corporate computing, but if you follow this road, embrace this path, and do so with data that needs to be secure then this is what's coming to you the moment your data is specifically targeted, whether you like it or not.

View this entry with comments (registration required to post)

Let's focus just for a minute on the oft-repeated claim that the US Government's "agencies" have "declared" that Russia is behind the Podesta (and other) Wikileaks releases -- that is, they stole the data.

There's no evidence to support that which passes even the most-rudimentary sniff test.

You have one guy who's made that claim in the US -- Clapper.  The same Clapper who knowingly lied before Congress in the past.  Yes, that Clapper.

Now it is certainly true that Russia is likely capable of such a hack.  Then again the hack itself, as I've pointed out, isn't especially surprising given that it appears many of these "email accounts" have been sitting on public cloud-provided email services.

By definition such 'services' are not secure and cannot be made secure. That people like Podesta are using them for sensitive private matters (which the government is NOT entitled to copies of) such as campaign work is proof of their stupidity -- and little more.

Folks, I can set anyone up with a system that is virtually hack-proof for email, yet for those emails where you don't care about security you can still exchange them with anyone else.  I use such a system myself, built by myself.  Key to this sort of design is that unencrypted emails that you wish to be secure against tampering, interception or both are never stored on the server.

This is obviously unsuitable for the government and its official business (which is why they don't do that) because the government relies on being able to see what is going on both for routine business purposes and to comply with FOIA requests.  Obviously a classified network is an entirely different thing but an unclassified network used for government business stores and distributes unencrypted email because if it was otherwise nobody, including legitimate government oversight organs, could access it!

Let's assume you want to send me a secure email.  All you need to do is email me first, and ask me to reply to you.  Doing so will give you my public key for S/MIME.  You now use that key to encrypt your message (which modern email clients can do automatically) and send me the message you wish to send "securely."  Commonly-available client software which can do this includes Outlook (Microsoft's), Thunderbird, BlackBerry's Android phones (the Priv and DTEK50) and reasonably-recent Apple iPhone software, among others.  You can obtain a key pair for such a purpose from a number of places on the Internet, some of them free, and the better ones do not require that anything other than your public key ever touch their infrastructure, so the risk of them leaking your private key to others is zero (since they are never in possession of it.)

Said email can then pass through however many systems and be stored in however many places but if stolen it is unreadable (unless you saved an unencrypted copy in your "sent" folder), because the only place my private key happens to reside is on devices that I have physical control of.

It is most-specifically not on the server where the email resides!

Here's the important point to remember when it comes to public key cryptography: Once you encrypt the message to send it not even you can decrypt it again!  That is, the key you used for encryption is worthless to decrypt; you need the other half and you don't physically have it nor is it on the server.  Only the person you targeted the transmission toward has it.

So now to break in and steal that email you cannot "just" break into my server and steal the database or files full of messages (you get a bunch of encrypted messages, which you can't read) nor can you intercept the messages while they're being sent (ditto.)  Instead you have to steal both the encrypted message and an unlocked copy of my private key, which exists in unlocked form only while I'm actually using it and it is only present on my personal devices.

In other words you now have to catch me, personally, using said key and manage to get the device out of my hands and into yours, then get said device to divulge the key, before the device locks itself or detects your attempt at tampering (at which point you're screwed since they key is no longer unlocked and/or it has been destroyed!)

Is this possible?  Sure.  But it's a hell of a lot harder than stealing the email itself.  Why do you think the FBI, when they go to bust someone they think might be doing something illegal (like trafficking in kiddie porn) always want to catch the perp with his computer on and unlocked?  It is for this very reason -- seizing a computer that has an encrypted disk but is turned off is frequently going to result in them having exactly zero means of retrieving whatever is on there.  The only way around that is if there is a back door that will trick said device into divulging the encryption key (such as was the case for the infamous California shooter's iPhone.)

So what we have here is a group of people who are intentionally using insecure means to communicate and then whining when one of their own people leaves the front door unlocked.  Does this require some "Grade A" hacker to break in and rip it all off?  Oh hell no it doesn't; in fact, all it requires is that you be stupid, and apparently plenty of these people are.

Where did the hackers come from?  I strongly doubt it was Russia.  I would not be at all surprised to discover that it's nothing more than third-rate folks who send out spams that look like "password reset" requests; it only takes one time you fall for that and then, well..... yeah.  (Or something equally stupid, such as using the same password in a dozen different places, some of which use insecure hashing systems, one of those files gets stolen and the password cracked.  Now I don't have to break into anything since I have the actual password!)

All of this underlies one reality that I pointed out in an earlier column though, which is why none of the media will talk about this, why my phone hasn't rung with a request for an interview on the matter nor has anyone else's who knows what they're talking about: The moment it gets into the public consciousness that "cloud" computing is never secure at any time any a key is on said cloud or unencrypted data is stored or used there the "value" of all these public cloud companies, which are a huge part of the valuation bubble in the stock market today collapses.

So to summarize:

  • The campaign is full of stupid people who have been passing around sensitive data without encryption.  These are the people who the candidate, incidentally, thinks ought to be running in the country if she wins.  It ought to be obvious that putting stupid people in public office is a bad idea.

  • There are moderately easy ways to avoid this problem for sensitive communications where no central authority needs to be able to get to them for legitimate purpose.  The campaign decided not to do that, however, which goes directly to point #1 -- they're stupid.

  • Responding to a question about a leaked email with a "where did you get that" sort of response is demonstrable evidence that the allegations raised about said content are true.  If they're false (that is, the email was falsified and not really sent) then you'd instead get a categorical denial. Why would someone ask "where you got it" if they never said it in the first place?  A denial doesn't mean that the allegation isn't true, but questioning the source instead of the content is nearly-always an admission that the content is factual. Use your head folks.

  • The underlying issue related to these hacks is that so-called "public cloud" providers are insecure if, at any time, unencrypted data or the keys to decrypt said data are on said machines.  The value of a whole bunch of "new economy" bubblicious companies depend on this not making it into wide public consciousness because the minute that it does nobody is going to consent to their health data, their financial data or anything else that's personal and sensitive being put on this sort of infrastructure ever again.

In other words blaming Russia is a distraction intended to keep you from paying attention to both the content of the emails (which certainly appear to be factual given the reaction to their release thus far) and the fact that a whole host of data about you is being similarly stored in similarly-insecure fashion by literally thousands of companies.

View this entry with comments (registration required to post)

I was forwarded this column recently and have to comment on it.

The problem is that privacy and encryption aren’t built into our email systems and it’s not been a priority for software and device makers to improve the usability and everyday usefulness of security technologies.

Frankly, there aren’t practical ways for the everyday person to secure their communications from prying eyes, let alone sophisticated government spying.

Don’t Try Hosting Your Own Email

Unfortunately, hosting your own email is not likely the answer either.

If you choose to run your mail server on a shared virtual private server (VPS), your email is only as secure as your hosting company’s business protocols. And, you have to quickly keep up with the steady stream of zero day vulnerabilities such asHeartbleed, Freak, et al.

The argument: You shouldn't try what Hillary did because it's very difficult, natch, nearly impossible.


First, let's dispense with a few things.  There is no such thing as a "secure" email system that allows you to read encrypted messages on the web or similar.  This means Gmail and similar "webmail" applications are by definition not secure and cannot be made secure.

The reason for this is that in order to decrypt an email an unencrypted, unlocked key must be present where the encrypted data is present.  If you can read an email via a web browser then the unlocked, unencrypted private key must be on the server and if it's there it can be stolen.  If the server in question is a virtual machine it can be trivially stolen by anyone who happens to have administrative access to the VM host by directly reading the memory of the guest process.  If it's on a VM that is "sleeping" it can be trivially read from the file-backed RAM copy of the guest process.

Let me repeat: Secure email requires that the only place an unencrypted private half of a key resides is in a device that is physically under your control at all times when it is present.  That key must be either encrypted or not present at all at all other times and in all other places.

If you load an encrypted private key on your phone, with a strong passphrase, then when that key is not unlocked that's fine.  When you're using the phone and key is unlocked (so you can use it) that's fine too, provided it either automatically locks when unattended or you can lock it immediately when required (e.g. when putting the phone down, in your pocket, etc.)

As soon as you load an encrypted key on a device not in your immediate physical control and provide the password for it you have permanently destroyed its inherent security.  Whether it is stolen at that instant or not cannot be proved but it must be presumed to have happened.

Now let's talk about email transport and storage.

It is always valuable on a server you run, not a virtual machine somewhere (such as Amazon's or someone else's cloud) to operate with encrypted storage volumes if you can do so without materially compromising performance.  The reason for this is simple: Such encryption is very good at protecting the data if and when the machine is not in use.  That is, if someone steals the computer as soon as they unplug it they are in possession of some very nice blank disk drives.  That in turn means that if someone wants to attack your systems and try to get your data they have to do it while it's running, which means its defenses (such as they are) remain operational.  An unencrypted disk can be removed from its original machine and mounted on another, immediately rendering all of its data accessible.  Properly used disk encryption provides very strong resistance to what is otherwise a trivial means of data theft.

Again, if such "computer" is in fact some "cloud" instance somewhere, no matter where, then such "encryption" is worth exactly zero because the manager of said cloud machine can read the key right out of your virtual instance's memory!  Once he has done so he can use said key forevermore, and you'll never know he did it.  As such encrypted storage on a cloud instance is worth exactly nothing, which is the nasty little secret that all the wonderful cloud companies like Amazon and similar do not want to discuss (because it would destroy a huge part of their business), but it is nonetheless true.

Let me restate this in case you are dense and haven't bothered reading what I've said thus far: As soon as an unencrypted key is present on a machine you do not have physical control over (and thus security monitoring of some sort) it must be presumed to have been stolen.  This is always true for any virtual machine instance running on any cloud provider, period.

Now the good news is that for secure (encrypted) email you don't need to load an encryption key on the email server.

That is, the key can be (and should be!) present only on your personal devices under your personal control and if you lose personal control of any of them for any reason for any length of time when they are unlocked they must be considered compromised and re-issued.  You may choose to keep the old keys around (so you can read old emails) but you must consider those emails or files as potentially exposed.  If both the key and encrypted file(s) were taken they are compromised -- period.

The only purpose for encrypted transport of email traffic is to provide some authentication and evidence of where an email actually came from.  It serves exactly zero other purpose since if the actual text of the email itself is not encrypted on both ends then it is trivially easy to steal or modify it from the end-point servers, even in their data caches while it is being transported.  If you care at all about the security of the contents of an email then you must encrypt the contents which means it never, except in the editor and display software of the devices on each end, exists in unencrypted form.  Period.  (For simple attestation that it has not been modified a cryptographic signature is sufficient; it will not validate if even one character has been changed.)

Today, the best option for this in the context of email is called S/MIME.  The reason is key exchange; PGP is quite secure but a 5-alarm pain in the ass when it comes to key exchange since it has to be done manually and you must know the key of a correspondent to send them a message.  S/MIME inherently contains the key in any signed message so if you get a plain-text, signed message from me (which is how I send them by default) you can now reply to me encrypted, and as soon as I get that message I can reply to you since the normal protocol is to both encrypt and sign -- and your signature gives me your key.  This makes key exchange in the S/MIME world easy and "almost" automatic -- the only requirement is that we both have S/MIME keys.

Note that if you steal a disk full of my encrypted S/MIME received email it is worth exactly nothing to you because the private key you require to decrypt it is not on the server you just stole.  It is present only on my phone and other computing devices and it is only unencrypted (that is, unlocked) when in actual use.  As such if you steal a message aimed at me while in transport it does you exactly zero good, and if you steal my server (which is on my physical property) as soon as power is removed from it congratulations - you just stole what appears to be a bunch of blank disk drives since the drive key is ONLY present in RAM and erased as soon as power is removed or the server is shut down.

Let me make this clear in plain English because people seem to ignore it, including people who damn well ought to know better (most of whom, I argue, do know better):

1. The employment of encryption on any cloud service where the data is ever decrypted on that cloud is never secure because the memory of the decrypting process (and thus the decryption key) can be read from the virtual machine host (if the VM is running) or the instance's memory image file (if it is shut down.)  This access takes place outside of the "instance" of the cloud computing in question and thus is not subject to its access controls and security, such as it may be.  For this reason any implementation on a public cloud that involves storing and accessing allegedly "encrypted" data is insecure, period, and to the extent such security is required a matter of policy or law you are not in compliance and anyone who claims you are is either intentionally ignoring what said policy or law requires or is ignorant of how cloud computing operates.  Utterly nobody wants to talk about this in the technology sphere as this would have a severe, immediate and irreparable impact on the outrageous bubble in said cloud computing companies but it is nonetheless true.

2. Secure email requires that a message is decrypted only at the point-of-use which is never outside of your direct physical control and at all other times, including when stored on a mail server, it remains encrypted.  This means that there is no such thing as secure email that is accessible via a web browser, period.  It means there is no such thing as secure email that is accessible via an app that does not perform decryption internally on the end-user's device.  Gmail, Hotmail and similar which all provide for web interfaces and are publicly-available resources are explicitly incapable of being secure for this reason.

3. To restate #1 in a more-succinct manner, no cloud computing platform has secure storage available -- period -- because the keys to same are always accessible by someone outside of the cloud instance in some form or fashion. 

4. No, it's not worthless to set up your own email and run it, nor is it particularly difficult to do so in a secure fashion.  Whether transport and storage is secure is immaterial if at all times the stored and transported email are encrypted; the interception or theft of same is of no value in that instance because the only time the email is decrypted is when it is being read on the end-user's device they are holding in their hand, lap, or which sits on their desk.

That Hillary and her staff were both incompetent to an extreme degree does not make the task impossible, but before you undertake a task you must first understand what you are doing to have a crack at success. Clearly, neither Hillary or her staff did, and the results were disastrous.

View this entry with comments (registration required to post)

Ok, folks, I've had enough of Ted Cruz and a handful of others trying to fundraise on the back of the Internet handover issue.

First, this is not a surprise nor something Obama cooked up in the dead of night.  The expiration of the existing arrangement has been known for literal years and the timing of same has been known for the same amount of time.  If the US Congress wanted to intervene it has had years to do so and has intentionally not done so.  So to Ted Cruz and others (Jim DeMint anyone?) who is now claiming "emergency", go perform an anatomically-impossible act; if you were more-focused on policy and less on your own horse**** you would have dealt with this months or even years ago.

Second, on to the technical side: There are two rough components to Internet "governance."  The first is handled through domain name registration.  Originally this was all handled under government contract by a government-dished out monopoly.  During that time domains were $50/year plus whatever the ISP that registered them for you and ran your DNS charged, and it often took days (instead of seconds now) to get a domain registered.  These were COM/NET/ORG/MIL/GOV/EDU and the country code domains; in the US that was .US.  This changed through a quite-contentious (and, IMHO, a rather cronyism and lie-laced) process into what we have now with many TLDs.  I will note that the so-called cognoscenti of the time tried to claim that expanding the TLD list on a material basis was not going to work for technical reasons.  Those people, who happened to include some of the self-claimed "brightest minds" in the Internet space who even today are lauded as "the inventors" and "bright minds" were lying -- not mistaken, lying.  I proved this (after much experimentation so I knew I was right) back in the 1990s with a handful of other ISPs when we set up our own private root and started opening up TLDs on a non-collision basis -- it was called eDNS.  The project collapsed when one of the participants did a handful of things that were quite-arguably illegal and definitely (from my point of view) anti-social -- but in terms of the technical side of things it was a complete -- 100% -- success.

In short there is utterly no technical reason to limit top-level domains with any rational number of suffixes (that is, the right-most part of the name before the first dot proceeding left.)  "Rational" has an upper limit somewhere, but it's in the thousands if not tens of thousands.

Note that running an actual root nameserver is a quite-low overhead thing.  The reason is that the top-level zone names change infrequently, so the "time to live" field is set long on them.  This means they're queried infrequently; a new host coming up on the Internet that provides name resolution for users must ask at least one of those root servers on a "time to live" basis for the nameserver for each top-level domain it wishes to resolve (so it knows where to send the query.)  But once you have the nameserver list for .COM you have it, no matter how many .COM domains you then resolve -- until the time-to-live comes up.  Because this data is infrequently changed data and the request is only for the place to ask for the next level down the bandwidth and CPU requirements are extremely modest, even with a very large TLD list.

The bigger and more-silent issue in terms of public attention is the allocation of IP addresses.  These are the actual numbers that denote the address of a site.  Legacy addresses are called IpV4, which are in the form x.x.x.x, with each of the "x"s being between 0 - 255 (8 bits.)  All zeros and all ones are reserved (for local network broadcast) and there are some other specials as well (127.x.x.x being a notable one.)  This used to be strictly delineated by the prefix (the first digit) into classes but by the mid 1990s a specification called CIDR made that more-or-less obsolete.  There were, and probably still are, quite nasty practices, all political and arguably in many cases anti-competitive, that revolve around allocations of addresses.  Part of the problem stems from the fact that a handful of extremely large firms got ridiculously large allocations (16 million addresses, for example) that they'd never need uniquely-visible from the outside yet they considered them an "asset" (think places like IBM and AT&T) and with only 4 billion possible addresses there was a very real issue with running out -- especially when some people were only using a fraction of a percent of what they had been allocated!

This was "solved" years ago with the introduction of IpV6 (or IPng), which contains eight octets instead of four.  This allows what amounts to an effectively-inexhaustible resource since you could have (for example) 4 billion internet providers (in the left 4 octets) each of which with 4 billion end addresses (in the right 4.)  A customer who moved from one to another would not have to change any of the right side addresses at all because he could change the prefix instead.  In practice it doesn't work quite this way, but that's the essence of it.

IPng also can, with proper management, make the Internet routing table (much) simpler and smaller.  Right now there is a huge problem with route table bloat and it has been a problem since the early 1990s!  In fact in the early days of the Internet it literally forced obsolescence of $100,000+ routers at a large number of ISPs, including mine, because their architecture did not support adding any more RAM and the table got big enough to run them out of room, causing them to crash.  The nature of fragmented address assignment in IPv4 makes for a serious problem because a given ISP might have dozens of address assignments each of which requires a route table entry; under IPv6, reasonably managed, this drops to one.  And oh by the way, one of the arguments then by big telcos and similar firms was "well, if you're serious then replacing anywhere from one to a number of $100,000 devices is not a big deal."  Yes, this was what they said because, you know, limiting competition to only those who had a lot of capital through collusive acts is a perfectly legitimate practice (yes, that's sarcasm, and if you need to understand why go read 15 USC Chapter 1.)

So why isn't "everyone" on IPng?  Mostly because there is a lot of equipment and software out there that cannot handle IPng at al.  There are entire ISPs that even today can't handle it network-wide including some of the large consumer providers such as Cox.  While there are potential technical solutions to this in the form of tunnels the political implications between ISPs of ramming that down people's throats has not gained traction.

Ok, enough backstory.

Now to the practical side of things.

It is important to understand that so long as you do not create collisions in the namespace (e.g. DNS) you harm nobody by setting up your own domain service.  This means that if, for example, China wishes to "censor" .****china as a top-level domain it can do so, but anyone else does not have to adhere to that and so long as nobody "collides" by defining different ".****china" TLDs in their configuration nothing will break.

In addition it important to note that even under the current, pre-handover paradigm a nation-state has always been able to mandate such censorship and in fact any private entity has been able to enforce same for their users as well!  In other words there has never been anything preventing China from (for example) declaring as a matter of law that any ISP inside their nation must use a 'root' server set inside China that omits the declarations for ".****china".  An ISP that does not want ".xxx" or ".sex" available can run its own root, enforce that for its clients by refusing to pass port 53 traffic outside of its network for internal clients and omitting it from its own private root.  Note that whether those root servers are "official" or not (as declared by ICANN) is immaterial; again, so long as there is no "collision" it has exactly zero impact on the functioning of the Internet, except for "black holing" those "forbidden" spaces.

This is not new; it has been this way literally forever since the dawn of DNS when the Internet transitioned in its earliest days from an /etc/hosts file to DNS.

The other half, that of allocating IP address space, appears to be more serious but again it really isn't.  Why?  Because the wisest use of the prefix length is to segregate traffic anyway. It's arguable, in fact, that geographic segregation might be the most-efficient (e.g. by country) although that is not necessarily true anymore with so many trans-national firms.  Nonetheless the handing out of high-level, that is, large prefixes is not really impacted here and yet it is the only function of ICANN in this regard.  It is the regional or national registries beyond that top level that manage address space internal to a given region or nation.

In Europe for IPv4 this has been done by RIPE.  In Asia, APNIC, and so on.  This hasn't changed and won't.  What changes is who (in persons, not organization name) hands off blocks to RIPE, APNIC, etc.  While there is a very real risk in the IPv4 space of interference due to scarcity such is not realistically a factor for IPng simply due to its size.

What does this all mean in terms of the alleged "handover" and thus what is the risk of "censorship" and similar, beyond what can and does already happen?

Damn little.

With that said I happen to support blocking this move, simply because I'm not convinced that anyone has done the homework to prevent this from turning into yet another multinational boondoggle.  UN anyone?  UN "peacekeepers" raping and pillaging those they are claiming to help anyone?  Yeah, that's a problem, but it's a different class of problem than "oh my God, the Internet will die and be censored if some bad person does X."

Uh, no it won't -- at least not any more than it already has.  But in my opinion corruption has already been an issue when it comes to DNS and IP addresses, and that was with a monopoly contract as we have now, albeit in an earlier form -- 20+ years ago!

To potentially enlarge that corruption is bad.  To lessen it would be good, but thus far nobody has managed to convince me that this transition would lessen it -- reality is that "as designed" we wind up keeping it at the present level.  For this reason I'm opposed, but note that the current screamfest has exactly nothing to do with corruption and everything to do with imaginary bogeymen that do not exist.

Finally, unlike most of the so-called "pundits" and all of the politicians I actually have plenty of relevant experience in this area and know what I'm talking about.

View this entry with comments (registration required to post)

Main Navigation
MUST-READ Selection:
The CERTAIN Destruction Of Our Nation

Full-Text Search & Archives
Archive Access
Legal Disclaimer

The content on this site is provided without any warranty, express or implied. All opinions expressed on this site are those of the author and may contain errors or omissions.


The author may have a position in any company or security mentioned herein. Actions you undertake as a consequence of any analysis, opinion or advertisement on this site are your sole responsibility.

Market charts, when present, used with permission of TD Ameritrade/ThinkOrSwim Inc. Neither TD Ameritrade or ThinkOrSwim have reviewed, approved or disapproved any content herein.

The Market Ticker content may be excerpted online for non-commercial purposes provided full attribution is given and the original article source is linked to. Please contact Karl Denninger for reprint permission in other media, to republish full articles, or for any commercial use (which includes any site where advertising is displayed.)

Submissions or tips on matters of economic or political interest may be sent "over the transom" to The Editor at any time. To be considered for publication your submission must include full and correct contact information and be related to an economic or political matter of the day. All submissions become the property of The Market Ticker.