SHARE
TWEET

Untitled

a guest Apr 12th, 2014 43 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. Dear Polimedia,
  2.  
  3. In casually researching the Cardano I came across your announcement on Cryptome:
  4.  
  5. http://cryptome.org/2013/10/bitcoin-usb-gpg.htm
  6.  
  7. Which includes, in part, "Critique of the product welcomed."  I would like to prepare such a critique as well as suggesting major architectural choices for a Cardano B - which may be sold alongside Cardano A.
  8.  
  9. Overall, I love the "idea" of the Cardano: as described in your introduction to its specs, it allows one point of certainty in an uncertain world. However insecure a computer might be to which it is connected, so long as a Cardano does not leave your possession, its private key can be relied on to work, and to be uncompromised, while it remains on the physical Cardano which does not export it under any circumstances.  Moreover, you can actually use that private key while preserving the above guarantees.
  10.  
  11. I like this idea very much.  A point of certainty in an uncertain world.
  12.  
  13. *HOWEVER*, as someone who has done product management on companies with a market value in excess of $100B, I can tell you that architectural assumptions which might seem the most certain from the point of view of the drawing board, can have unintended consequences.
  14.  
  15. As beautiful as the idea is, the Cardano in its present form is _unfit for any purpose whatsoever_, as I will prove shortly.
  16.  
  17. If interested in my follow-up proposal, I can prepare a more detailed overview detailing this conclusion.  The main points are summarized below.
  18.  
  19. For my follow-up proposal, I would like to tie the detailed report also to acceptance of my proposal to prepare a more detailed, albeit high-level, design document for the Cardano B - of between 20 and 50 pages, detailing high-level architecture based on the idea of the Cardano, and intended to address a market 10,000 times larger in size than the Cardano A addresses.  (i.e. for each 100 people who fall into the target market of the Cardano A and may buy one, 1,000,000 people fall into the target market of the Cardano B, and may buy one.)  My proposal is at the end of this email.
  20.  
  21. (SUMMARY) THE CURRENT VERSION OF THE CARDANO - UNFIT FOR ANY PURPOSE
  22.  
  23. Some basic reasons the Cardano A - as I'll call your current version - is unfit for any purpose is as follows:
  24.  
  25. ------------------------------------------------------------------------------------------------------------------------
  26. 1. The more Cardanos are sold, the less secure each Cardano gets. (Password hashing argument).
  27.  
  28. 2. The Cardano does not rely on Public Key Infrastructure between the insecure host device and the secure Cardano - why should it? But this design choice is wrong and must be mitigated. (MITM argument)
  29.  
  30. 3.  Leaky abstraction: the Cardano is supposed to be built so that it can perform one verifiable action without additional trust involved.  The only guarantee is that the key used to perform the action will not be leaked except through loss of possession of the Cardano.  Unfortunately, the abstraction leaks heavily, and a large measure of additional trust is silently involved. (Evil device argument.)
  31.  
  32.  
  33.  
  34. Let me take these in turn.
  35. ------------------------------------------------------------------------------------------------------------------------
  36. 1. The more Cardanos are sold, the less secure each Cardano gets. (password hashing argument).
  37.  
  38. Let me post a simple question: why are servers expected to store hashes of their users' passwords, and not the actual passwords in the plain?
  39.  
  40. This is a simple question. In a sense, a hash "shouldn't help": once the server has been compromised, its software can do anything, including logging all users' data and passwords in the plain.  Since users are expected to submit passwords to servers, what difference does it make whether they're stored hashed or in the plain?  Either the server is compromised or it isn't.
  41.  
  42. The difference is, quite simply, that people reuse passwords across sites, and that although servers are expected to remain secure, a trove of unencrypted passwords makes them a more valuable target.   The plain passwords are valuable.  If the server does not store the unhashed passwords, then the only real worry is passwords that are submitted from between the time the server is compromised to discovery of the compromise.  Not every password ever entered into it.
  43.  
  44. The more unhashed passwords on a server, the bigger target it becomes, and the worse the fall-out should it be compromised, however briefly.
  45.  
  46. The Cardano, by design, does not require any password to use.  Therefore, every Cardano that has ever been shipped by your company, represents one address in a list of addresses that are using a private key in a device which does not include any password on it.  This would be worrying enough if you needed to store only an email address in order to send someone a license key to some piece of software: but the real world doesn't work that way.  You have to have a full shipping address -- a shipping company or courrier, with whom you have an account, and who has a record of your deliveries.  You are physically delivering somewhere.
  47.  
  48. So long as you have 100 users, that is not very worrying.  If you had 100,000 - then that trove of addresses would be very valuable.  Like a server storing passwords, you are expected to remain secure.  And yet the fact that the Cardano does not include functionality for inputting a password, means that the more Cardanos are sold  - the less secure each one gets.  The bigger a target are you, your couriers, your payment processors, indeed, anyone who might learn your customer base.
  49.  
  50. On the other hand, if each Cardano needed a password, then suddenly you would no longer represent a list of addresses which contain a plain keysigning mechanism.  It would be like a list of hashed passwords, instead of passwords in the plain.
  51.  
  52. It is a minor point, but an important one.   If the Cardano became a valuable tool, then the fact that it does not come built with a password means that your customer list is a list of people who must walk about with a stick of gold, if they are to use it from a public computer.
  53.  
  54. Ask yourself this: if you were in the business of shipping a stick of gold out to customers, and your usage case were for them to use this stick of gold from a public library - would you want your customer list to be tantamount to this information about their habits?
  55.  
  56. Mitigation: the only mitigation is for Cardanos to come with a password that is unknown and unknowable to the manufacturing and shipping company, effectively hashing the list of addresses that contain a Cardano-in-the-plain.
  57.  
  58. ------------------------------------------------------------------------------------------------------------------------
  59.  
  60. 2. The Cardano does not rely on Public Key Infrastructure between the insecure host device and the secure Cardano - why should it? But this design choice is wrong and must be mitigated. (MITM argument).
  61.  
  62. The Cardano is supposed to be a secure point in an insecure world.  To that end, its basic architectural assumption is simple: the devices to which it connects must be considered insecure, and the Cardano escrows its private key and communicate only signed files, never divulging the key.
  63.  
  64. To this end, the chosen architecture is a USB connection, over which files can be given to the Cardano, and signed results returned.
  65.  
  66. So far so good.
  67.  
  68. But there is a problem.  USB is a totally insecure channel.  It does not in any way ensure any security between the Cardano and the insecure computer.
  69.  
  70. It is trivial to imagine a man in the middle attack.  Someone sees you at a public library, signing documents with your Cardano.  They want you to sign something, and use it with immediate effect, for example to approve a large transaction in your name with immediate effect.
  71.  
  72. Before you get back to the computer, they have made a small change.  They have opened the PC and installed a small USB device that acts like a USB host, only it has some malicious programming.  It connects to a USB slot and the attacker replaces the visible USB slots with the USB slots of the evil USB host   The host has very special properties, and does deep inspection and replacement of the USB traffic.  (It could be a complete android PC that acts as host and device.)
  73.  
  74. When you send a file to the Cardano, 99% of the time the evil controller transfers them to the Cardano normally, until you are used to this behavior and take it for granted.  Why should it not?  However, one day, at the attacker's whim, instead of the file you sent, it instead replaces the file with a file of the attacker's choosing.  You are powerless to know what, exactly, has gone across the USB channel.  The Cardano gives no confirmation, or feedback, as to what it actually signed.  (You can react by trying to test the signatures, but this is reacting - after the fact)   Once signed, it could instantly transmit the signed document over the air to the attacker, who begins using it instantly.
  75.  
  76. How can you protect yourself in those first few seconds?  Something different has been signed in your name from what you authorized, and you do not know this yet.  The entire Internet connection of the whole library could go down.  Cell phones could be jammed.  Just after the document has been signed.  How will you recall it then?
  77.  
  78. You have now signed something you will not have any way of recalling for some time.  Because the Cardano will sign whatever it gets, over an insecure connection, subject only to your asking it to, without knowing from the device what it is signing.
  79.  
  80. As far as escrowing your key - game over . The Cardano has lost.  You've signed something you did not authorize, without even knowing it.
  81.  
  82. True, a few seconds to minutes later you might (or might not) become aware of this).  The attacker might be clever and try to hide this fact, cause a distraction, expose a corrupt file to the insecure computer - or simply an earlier file you had already prepared - or in a thousand different ways attempt to gain a bit of time.
  83.  
  84. Eventually, of course, you can check the signed-count on the file.  You can try to run verifications of the signed document, again from your insecure computer (which by definition is meaningless - if your checking habits can be learned, they can be faked from the insecure computer in a gaslighting attack) so, usually, from another location.  If you realize that you must have signed something you didn't intend - something you have no evidence of, then you must invalidate your key.
  85.  
  86. Even though you could be "just imagining" things, as the only evidence you would have - as the Cardano does not keep copies of signed files - that the count may be off by 1, or the insecure PC may be seeing an old file or no file at all.  It could even be a simple error on the PC or even on the Cardano.  Who would suspect that, in fact, time is ticking and you have signed something you did not authorize?
  87.  
  88. What is the solution to this issue?  How can this be resolved?
  89.  
  90. Well it turns out it could be resolved extremely simply.  If the Cardano had any sort of display it could simply display the hash value of what it was about to sign: the user would manually have to click through to approve that particular hash.
  91.  
  92. It is a bit difficult to add this to the physical device.  However, I would say that it is necessary at a minimum if the user is to use the Cardano over a channel which itself is insecure.  On the current hardware, you can do Morse with the LED's to type out the hash of the file it is about to sign, and a mobile phone with camera could read the LED, if you didn't know how to read morse.  This would, of course, expose a channel for the hash information to leak - as would any LED's - however the alternative of signing something sign unseen, after receiving it over an insecure channel, is unacceptable.
  93.  
  94. The other alternative is to use PKI between the Cardano and the insecure computer.  This would at least make the MITM attack a bit more difficult.  It is not supported by the USB protocol.
  95.  
  96.  
  97. On the subject of USB...
  98. ------------------------------------------------------------------------------------------------------------------------
  99. 3.  Leaky abstraction: the Cardano is supposed to be built so that it can perform one verifiable action without additional trust involved.  The only guarantee is that the key used to perform the action will not be leaked except through loss of possession of the Cardano.  Unfortunately, the abstraction leaks heavily, and a large measure of additional trust is silently involved.
  100.  
  101. Here is a simple question.  Is it okay to plug a Cardano just received, into a trusted PC?
  102.  
  103. Through the abstraction that has been exposed to the user, the answer would seem to be, ”yes – why not?”  After all, the only way in which the Cardano could ”break” or fail to perform its stated purpose, is by somehow leaking the private key, or failing to sign documents (an obvious failure, as the signed documents can be verified.)  Neither is an issue when connecting to a secure PC.  In fact, the whole raison d'etre of the Cardano is that the PC need not be trusted.
  104.  
  105. On its surface, it would seem that if the Cardano is connected to a secure PC, both of the failure scenarios are relatively easy to detect, and not of particular concern: either the Cardano is signing as requested or it isn’t, which can be detected easily enough.  If it has been compromised, then at most the private key has been leaked.  The device is not entrusted with any additional privileges on the USB host computer, except as acting as a mass storage device.
  106.  
  107. In the case of an evil Cadrano, what else could happen?
  108.  
  109. Unfortunately, it is far from the case that there are no security ramifications to plugging in a Cardano.  Where the abstraction breaks down is that USB devices do, in fact, enjoy a very large measure of trust by all modern operating systems.  For example, this is why USB keyboards are simply added silently by default on all modern operating systems.  They can begin to type commands to see if they are at a shell, and if they get one, try to escalate privileges.  Most operating systems do not make any attempt to mitigate against this threat.
  110.  
  111. Likewise, a review of the literature shows modern USB stacks to be incredibly buggy, prone to attacks on several fronts.  In addition, nearly all modern Operating Systems have individual USB device drivers which are buggy and can be exploited to escalate privileges.   An overview of the rough challenges is here, though better ones could be found.
  112.  
  113. http://theinvisiblethings.blogspot.hu/2011/06/usb-security-challenges.html
  114.  
  115. Essentially, the primarily issue raised in this point is that there is an abstraction raised by ther Cardano, but in its implementation it is wrong.  By plugging what we perceive to be a Cardano into a trusted USB slot, in fact we are entrusting the Cardano with root privileges on the host machine – by virtue of the design and implementation details of the USB architecture.  It is simply not an untrusted channel that is hardened.
  116.  
  117. What is the fundamental design reason for this insecurity in the USB stack? Shouldn’t it be more secure? Simple.  USB host control designers and operating system designers know that if someone has physical access, it is already a case of ”game over.”  So attempting to harden the USB stack is rather silly.  In the end, this is the reason why USB hardware and software stacks are not particularly hardened against various vectors.  The case of plugging a malicious USB device into a trusted PC, and expecting the PC to treat the malicious device at arms length, is the not the actual state of the art in computer security.  USB devices have many avenues of attack.
  118.  
  119. (To name just one, a modified Cardano could simply expose a USB keyboard at an unusual time and start typing.  If it works, it could quickly type a small script to rewrite the screen, minus the guilty line, as well as begin to watch the real keyboard for events, and in case they happen to quickly remove traces of itself.  Rewriting the screen to remove the guilty line (which nobody would associate with the Cardano) would take a tiny fraction of a second after entering the bash script.  The whole thing could happen in a single blink of an eye at 4 AM.  Even a person watching attentively might well conclude that they were imagining things.  As soon as the script had been entered, giving the Cardano a way to enter commands that were hidden, it could begin to attempt to escalate to root.  Or simply present a fake interface that watches for a sudo password, for once the user comes back in the morning, thinking they were at their old prompt.)
  120.  
  121. The possibilities are endless.   Given how much trickery can be performed, it is a wonder why USB Keyboards would be added automatically by default on all modern operating systems to begin with.
  122.  
  123. The answer is simple: *because USB implies physical-level access*.  This is simply one of the last and least important vectors that are hardened architecturally.
  124.  
  125. Architects no more try to seriously harden USB as they try to harden RAM from leaking its electrical signals to a distance of a few thousandths of a millimeter.  If someone is that close to the RAM, mitigation is meaningless and they must be assumed to have full physical access.
  126.  
  127. And so this choice of vector must be explicitly told to the user:
  128.  
  129. -->     Unless you trust us absolutely, you must consider the while you trust the Cardano, we have complete access to any PC it is connected to.
  130.  
  131. So the user cannot plug the Cardano into a secure PC.  Meanwhile, however,
  132.  
  133. -->    The Cardano is susceptible to a MITM attack at an insecure PC.
  134.  
  135. So the user cannot plug the Cardano into an insecure PC.
  136.  
  137. If the user cannot plug the Cardano into a secure PC (at the stated level of abstraction), and the user cannot plug the Cardano into an insecure PC, then the Cardano A is unfit for any purpose.
  138.  
  139. At a minimum both of these attacks must be mitigated.
  140.  
  141. ------------------------------------------------------------------------------------------------------------------------
  142.  
  143.  
  144.  
  145. This is a general overview of the way in which the Cardano is unfit for any purpose today.  The analysis does not depend on very specific implementation details - but rather, on the high-level architecture chosen as well as a frank reading of the abstraction (interface; suggested usage) offered to the user.
  146.  
  147.  
  148. I am in love with the idea of the Cardano, and would be extremely interested in suggesting improvements to the Cardano A that would mitigate all of these vectors and make it supremely fit for purpose.
  149.  
  150. In addition, I believe that the idea behind the Cardano - the Idea - has a target audience of 100 million people.  I would propose suggesting a 20-50 page high-level (architecture-level) design document outlining the architectural proposal for the Cardano B.  It would be the same basic idea - a very good idea - brought to a far wider audience.
  151.  
  152. Ordinarily it is impossible to buy a clean and elegant high-level design that appeals to a hundred million people for $500,000.  (half a mil.)
  153.  
  154. I am happy to provide the above services at 5% of that cost, i.e. for $25,000 - paid half up-front in BTC (about 54 BTC) and half upon project completion (about 54 BTC).
  155.  
  156. The project is a simple high-level design document.  It will take me approximately 6 weeks plus a lifetime already amortized.
  157.  
  158. I very strongly support your project and beleive you can bring it to a very wide audience, and will vastly improve the state of security world-wide in doing so.
  159.  
  160. I hope you will give it all do consideration and respond at your earliest convenience.
  161.  
  162. The above analysis is not public and for your consideration persuant to my proposal, only.
  163.  
  164.  
  165. Rob Whiz
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!
 
Top