Congratulations!

[Valid RSS] This is a valid RSS feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

Source: http://feeds.feedburner.com/SteveGibsonsBlog

  1. <?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
  2. xmlns:content="http://purl.org/rss/1.0/modules/content/"
  3. xmlns:wfw="http://wellformedweb.org/CommentAPI/"
  4. xmlns:dc="http://purl.org/dc/elements/1.1/"
  5. xmlns:atom="http://www.w3.org/2005/Atom"
  6. xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
  7. xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
  8. xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
  9. >
  10.  
  11. <channel>
  12. <title>Steve (GRC) Gibson&#039;s Blog</title>
  13. <atom:link href="http://steve.grc.com/feed/" rel="self" type="application/rss+xml" />
  14. <link>http://steve.grc.com</link>
  15. <description>Steve&#039;s Public Brain Dumping Ground (watch where you step!)</description>
  16. <lastBuildDate>Tue, 03 Jun 2014 00:34:44 +0000</lastBuildDate>
  17. <language>en</language>
  18. <sy:updatePeriod>
  19. hourly </sy:updatePeriod>
  20. <sy:updateFrequency>
  21. 1 </sy:updateFrequency>
  22. <generator>http://wordpress.com/</generator>
  23. <cloud domain='steve.grc.com' port='80' path='/?rsscloud=notify' registerProcedure='' protocol='http-post' />
  24. <image>
  25. <url>http://s0.wp.com/i/buttonw-com.png</url>
  26. <title>Steve (GRC) Gibson&#039;s Blog</title>
  27. <link>http://steve.grc.com</link>
  28. </image>
  29. <atom:link rel="search" type="application/opensearchdescription+xml" href="http://steve.grc.com/osd.xml" title="Steve (GRC) Gibson&#039;s Blog" />
  30. <atom:link rel='hub' href='http://steve.grc.com/?pushpress=hub'/>
  31. <item>
  32. <title>This BLOG disappears tomorrow!</title>
  33. <link>http://steve.grc.com/2019/05/13/this-blog-disappears-tomorrow/</link>
  34. <comments>http://steve.grc.com/2019/05/13/this-blog-disappears-tomorrow/#comments</comments>
  35. <pubDate>Mon, 13 May 2019 17:51:15 +0000</pubDate>
  36. <dc:creator><![CDATA[Steve Gibson]]></dc:creator>
  37. <category><![CDATA[Uncategorized]]></category>
  38.  
  39. <guid isPermaLink="false">http://steve.grc.com/?p=740</guid>
  40. <description><![CDATA[WordPress has just notified me that my annual contract for &#8220;domain forwarding&#8221; with them will be expiring tomorrow.  So this is my final &#8212; before it disappears &#8212; reminder that I have a NEW self-hosted blog over at https://blog.grc.com where &#8230; <a href="http://steve.grc.com/2019/05/13/this-blog-disappears-tomorrow/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
  41. <content:encoded><![CDATA[<p style="text-align:left;">WordPress has just notified me that my annual contract for &#8220;domain forwarding&#8221; with them will be expiring tomorrow.  So this is my final &#8212; before it disappears &#8212; reminder that I have a NEW self-hosted blog over at <strong><a href="https://blog.grc.com">https://blog.grc.com</a></strong> where I&#8217;ll be posting anything of interest in the future.</p>
  42. <p style="text-align:left;">If you haven&#8217;t yet, please consider jumping over there and subscribing to that one so that you&#8217;ll be notified if anything I post.  My next planned posting there is an explanation of <strong>my plans for SpinRite&#8217;s future development.</strong>  <img src="https://s0.wp.com/wp-content/mu-plugins/wpcom-smileys/twemoji/2/72x72/1f642.png" alt="🙂" class="wp-smiley" style="height: 1em; max-height: 1em;" /></p>
  43. <p>And&#8230; thanks very much for your interest!</p>
  44. <p>/Steve.</p>
  45. ]]></content:encoded>
  46. <wfw:commentRss>http://steve.grc.com/2019/05/13/this-blog-disappears-tomorrow/feed/</wfw:commentRss>
  47. <slash:comments>1</slash:comments>
  49. <media:content url="http://1.gravatar.com/avatar/a604d67a7804cad916465d435e73a55c?s=96&#38;d=monsterid&#38;r=G" medium="image">
  50. <media:title type="html">agilesynapse</media:title>
  51. </media:content>
  52. </item>
  53. <item>
  54. <title>We&#8217;re Moving!  Come on over and check-out the new place!</title>
  55. <link>http://steve.grc.com/2019/04/18/were-moving-come-on-over-and-check-out-the-new-place/</link>
  56. <comments>http://steve.grc.com/2019/04/18/were-moving-come-on-over-and-check-out-the-new-place/#comments</comments>
  57. <pubDate>Fri, 19 Apr 2019 02:19:42 +0000</pubDate>
  58. <dc:creator><![CDATA[Steve Gibson]]></dc:creator>
  59. <category><![CDATA[Uncategorized]]></category>
  60. <category><![CDATA[Gibson]]></category>
  61. <category><![CDATA[GRC]]></category>
  62. <category><![CDATA[SpinRite]]></category>
  63. <category><![CDATA[SQRL]]></category>
  64.  
  65. <guid isPermaLink="false">http://steve.grc.com/?p=737</guid>
  66. <description><![CDATA[Yo!! After a long time without generating headlines, things are about to start hopping at GRC My 5+ year project to address the website login nightmare by eliminating usernames and passwords has its own web forum with more than 1,014 &#8230; <a href="http://steve.grc.com/2019/04/18/were-moving-come-on-over-and-check-out-the-new-place/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
  67. <content:encoded><![CDATA[<p>Yo!!</p>
  68. <h2 style="text-align:center;"><span style="color:#993300;">After a long time without generating headlines,</span><br />
  69. <span style="color:#993300;">things are about to start hopping at GRC</span></h2>
  70. <p>My 5+ year project to address the website login nightmare by eliminating usernames and passwords has its own web forum with more than 1,014 participants at last count. They&#8217;re all using their SQRL identities to login with SQRL clients for Windows, iOS, Android and a web extension for Firefox, Chrome and the new Chromium version of Edge. (And you can too!)</p>
  71. <p>The instant I no longer need to be working to get SQRL finished, a day which is fast approaching, I will immediately be back to work on the long-awaited upgrade to SpinRite 6.</p>
  72. <p><strong>This blog</strong> has always been hosted at WordPress.org on their servers. But I&#8217;ll be hosting this blog&#8217;s successor and replacing this one. Our contract here ends next month, and I&#8217;m ready with the replacement site&#8230; so <span style="text-decoration:underline;"><strong>THIS</strong></span> will be the final notice from this blog.</p>
  73. <p>Since you are subscribed here, I hope you will come over to our new location and re-subscribe there. (One of the many annoyances of not hosting our own blog is that I have no access to the list of this blog&#8217;s subscribers&#8230; so it&#8217;s up to you to re-join over there.)</p>
  74. <p>If you&#8217;re curious to learn more about SQRL, you will find links to the SQRL forums there. You can check them out, grab a SQRL client, create your SQRL identity  (it&#8217;s all free, of course) and see what I&#8217;ve been working on for the past five and a half years. I think you&#8217;ll find that the time was not wasted.</p>
  75. <p>The replacement blog is at:  <a href="https://blog.grc.com">https://blog.grc.com</a></p>
  76. <p>I hope to see you there!  Come on over and say HI!</p>
  77. <p>/Steve.</p>
  78. ]]></content:encoded>
  79. <wfw:commentRss>http://steve.grc.com/2019/04/18/were-moving-come-on-over-and-check-out-the-new-place/feed/</wfw:commentRss>
  80. <slash:comments>5</slash:comments>
  82. <media:content url="http://1.gravatar.com/avatar/a604d67a7804cad916465d435e73a55c?s=96&#38;d=monsterid&#38;r=G" medium="image">
  83. <media:title type="html">agilesynapse</media:title>
  84. </media:content>
  85. </item>
  86. <item>
  87. <title>The “Encryption” Debate</title>
  88. <link>http://steve.grc.com/2016/03/12/the-encryption-debate/</link>
  89. <comments>http://steve.grc.com/2016/03/12/the-encryption-debate/#comments</comments>
  90. <pubDate>Sun, 13 Mar 2016 02:49:35 +0000</pubDate>
  91. <dc:creator><![CDATA[Steve Gibson]]></dc:creator>
  92. <category><![CDATA[Uncategorized]]></category>
  93.  
  94. <guid isPermaLink="false">http://steve.grc.com/?p=475</guid>
  95. <description><![CDATA[“Encryption” is quoted in the title of this essay because encryption is NOT what any of this is actually about. The debate is not about encryption, it&#8217;s about access. It should be called “The Device Access Debate” and encryption should &#8230; <a href="http://steve.grc.com/2016/03/12/the-encryption-debate/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
  96. <content:encoded><![CDATA[<p>“Encryption” is quoted in the title of this essay because <em><strong>encryption</strong></em> is <span style="text-decoration:underline;"><strong>NOT</strong></span> what <strong>any</strong> of this is actually about. The debate is not about encryption, it&#8217;s about access. It should be called “The Device Access Debate” and encryption should have <em><strong>never</strong></em> been brought into it.</p>
  97. <p>Modern smartphones have batteries, screens, memory, radios, encryption, and a bunch of other stuff. Collectively, they all make the phone go, they are all good, and we want as much of each them as the device&#8217;s manufacturer can squeeze in. We do <em><strong>not</strong></em> want smaller batteries, lower resolution screens, less memory, less capable radios, or weaker encryption. And it is entirely proper for Apple to boast about the battery life, screen resolution, memory, radio, and encryption strength of their products. The FBI is entirely correct when it says that Apple is actively marketing the newly increased encryption strength of their latest phones and operating systems. That&#8217;s as is should be, in the same way that Apple is marketing their device&#8217;s battery life and screen resolution. Those are all features of modern smartphones, and Apple knows what their users want. We all want those things.</p>
  98. <p>The fourth amendment to the US Constitution states: <em>The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no warrants shall issue, but upon probable cause, supported by oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.</em></p>
  99. <p><em><strong>The 4th amendment is about managing access.</strong></em> It does <strong>not</strong> provide that under no circumstances, ever, can duly authorized law enforcement officials enter someone&#8217;s home. It provides a managed and monitored mechanism―a compromise―between the privacy rights of the individual and the needs of the citizenry who surround that person. And it is under this 4th amendment that US citizens have enjoyed the balanced guarantee that their home is their castle and that only a lawfully issued search warrant, meeting the test of probable cause, would allow law enforcement authorities a legal right to enter.</p>
  100. <p><strong>Mapping the 4th amendment onto encrypted devices:</strong><br />
  101. Without weakening their devices&#8217; encryption, Apple <em><strong>could</strong></em> arrange to be able to respond to court orders in the United States. If Apple wished to be able to respond to lawful search warrants to unlock their devices, they could embed a single, randomly derived, high-entropy (256-bit) unique per-device key in the hardware secure enclave of every device. This key would not be derived from any formula or algorithm, so there would be no master secret that might somehow escape or become known to a malicious agency. It would be truly random and <em><strong>far too lengthy</strong></em> for any possible brute force guessing attack to be feasible. Upon embedding each individual random per-device key, Apple would securely store a copy of that key in their own master key vault. In this way, without sacrificing anyone&#8217;s security, only Apple, on a device by device basis, could unlock any one of their own devices.</p>
  102. <p>This might appear to place an undue burden upon Apple. But this, too, seems balanced. Apple is, as the FBI correctly observed, obtaining great marketing value from the strength of their security technology. It is understandable that Apple would rather <strong>not</strong> be able to respond to court orders to unlock their devices. But this attitude is not in keeping with constitutional precedent.</p>
  103. <p>Users of Apple&#8217;s products would know that our devices sport the latest and greatest strongest encryption, making them utterly impervious to any attacker, hacker, border official, local or foreign government. And that as with the interiors of our homes, only in accordance with due legal process, and Apple&#8217;s continuing assistance, could our device be unlocked in compliance with a search warrant. And if, at any time in the future, Apple decided this was the wrong decision, they could destroy their vault of per-device unlocking keys and we would be no worse off than we are today.</p>
  104. <p>Although the perfect math of encryption <em><strong>does</strong></em> provide for absolute privacy, we all know that privacy can be horribly abused and used against the greater public welfare. The founders of the United States, whom many revere, understood this well. Apple should too.</p>
  105. <div style="background:#f8f8f8;font-size:smaller;line-height:130%;border:#888 solid 1px;padding:.5em 1em;">People who intend to comment: Please recognize that I understand there are many additional subtleties, such as handling the demands of foreign authorities. It is probably the case that the applicable laws of each country should be honored. This essay intended only to clarify the confusion between encryption and access, and the scheme I have proposed is sufficiently flexible to accommodate <strong>any</strong> specific access policy Apple might choose and/or change as needed.</div>
  106. <p>&nbsp;</p>
  107. <p><strong>Follow-up, 20 hours later:</strong><br />
  108. I wrote this post to separate the issue of encryption strength from access policy. Much ink and angst has been expended over phrases involving “backdoors” and “weakened encryption.” All such concerns are red herrings because unbreakable encryption simply gives Apple unbreakable access control. Apple <em><strong>could</strong></em> design a <em><strong>completely</strong></em> secure facility to manage unlocking individual devices. <em><strong>Whether</strong></em> Apple should do so is deservedly one of the most critical questions of our time, and is worthy of truly engaging debate. If we decide that we want to leave things as they are, that&#8217;s fine. But we should not conflate whatever policy Apple implements with their user&#8217;s security. We <em><strong>can</strong></em> have both.</p>
  109. ]]></content:encoded>
  110. <wfw:commentRss>http://steve.grc.com/2016/03/12/the-encryption-debate/feed/</wfw:commentRss>
  111. <slash:comments>111</slash:comments>
  113. <media:content url="http://1.gravatar.com/avatar/a604d67a7804cad916465d435e73a55c?s=96&#38;d=monsterid&#38;r=G" medium="image">
  114. <media:title type="html">agilesynapse</media:title>
  115. </media:content>
  116. </item>
  117. <item>
  118. <title>Yes&#8230; TrueCrypt is still safe to use.</title>
  119. <link>http://steve.grc.com/2014/05/30/yes-virginia-truecrypt-is-still-safe-to-use/</link>
  120. <comments>http://steve.grc.com/2014/05/30/yes-virginia-truecrypt-is-still-safe-to-use/#comments</comments>
  121. <pubDate>Fri, 30 May 2014 22:05:23 +0000</pubDate>
  122. <dc:creator><![CDATA[Steve Gibson]]></dc:creator>
  123. <category><![CDATA[Uncategorized]]></category>
  124. <category><![CDATA[GRC]]></category>
  125. <category><![CDATA[TrueCrypt]]></category>
  126.  
  127. <guid isPermaLink="false">http://steve.grc.com/?p=457</guid>
  128. <description><![CDATA[So opens the short editorial I wrote this morning and placed at the top of GRC&#8217;s new TrueCrypt Final Version Repository page. The impetus for the editorial was the continual influx of questions from people asking whether TrueCrypt was still &#8230; <a href="http://steve.grc.com/2014/05/30/yes-virginia-truecrypt-is-still-safe-to-use/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
  129. <content:encoded><![CDATA[<p>So opens the short editorial I wrote this morning and placed at the top of <a href="https://www.grc.com/misc/truecrypt/truecrypt.htm">GRC&#8217;s new TrueCrypt Final Version Repository page</a>.</p>
  130. <p><img class="aligncenter" src="https://www.GRC.com/misc/truecrypt/tc-logo.png" alt="tc-logo" width="100" height="99" /></p>
  131. <p>The impetus for the editorial was the continual influx of questions from people asking whether TrueCrypt was still safe to use, and if not, what they should switch to, and so on. By this time, one of the TrueCrypt developers, identified as David, had been heard from, and his interchange confirmed the essential points of my conjectured theory of the events surrounding the self-takedown of TrueCrypt.org, etc.</p>
  132. <p>Rather than repeating that entire editorial here, I&#8217;m posting this as <a href="https://www.grc.com/misc/truecrypt/truecrypt.htm">a pointer to it</a> since folks here have thanked me for maintaining a blog and not relying solely upon Twitter.  And also, this venue supports feedback and interaction which GRC&#8217;s current read-only format can not.</p>
  133. <p>Peace.</p>
  134. <p>/Steve.</p>
  135. ]]></content:encoded>
  136. <wfw:commentRss>http://steve.grc.com/2014/05/30/yes-virginia-truecrypt-is-still-safe-to-use/feed/</wfw:commentRss>
  137. <slash:comments>169</slash:comments>
  139. <media:content url="http://1.gravatar.com/avatar/a604d67a7804cad916465d435e73a55c?s=96&#38;d=monsterid&#38;r=G" medium="image">
  140. <media:title type="html">agilesynapse</media:title>
  141. </media:content>
  142.  
  143. <media:content url="https://www.GRC.com/misc/truecrypt/tc-logo.png" medium="image">
  144. <media:title type="html">tc-logo</media:title>
  145. </media:content>
  146. </item>
  147. <item>
  148. <title>An Imagined Letter from the TrueCrypt Developer(s)</title>
  149. <link>http://steve.grc.com/2014/05/29/an-imagined-letter-from-the-truecrypt-developers/</link>
  150. <comments>http://steve.grc.com/2014/05/29/an-imagined-letter-from-the-truecrypt-developers/#comments</comments>
  151. <pubDate>Thu, 29 May 2014 14:51:16 +0000</pubDate>
  152. <dc:creator><![CDATA[Steve Gibson]]></dc:creator>
  153. <category><![CDATA[Uncategorized]]></category>
  154.  
  155. <guid isPermaLink="false">http://steve.grc.com/?p=446</guid>
  156. <description><![CDATA[As I wrote yesterday, we know virtually nothing about the developer(s) behind TrueCrypt. So any speculation we entertain about their feelings, motives, or thought processes can only be a reflection of our own. With that acknowledgement, I&#8217;ll share the letter &#8230; <a href="http://steve.grc.com/2014/05/29/an-imagined-letter-from-the-truecrypt-developers/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
  157. <content:encoded><![CDATA[<p><a href="http://steve.grc.com/2014/05/28/whither-truecrypt/">As I wrote yesterday</a>, we know virtually nothing about the developer(s) behind TrueCrypt. So any speculation we entertain about their feelings, motives, or thought processes can only be a reflection of our own. With that acknowledgement, I&#8217;ll share the letter I think they might have written:</p>
  158. <div style="border:#000 1px solid;padding:1em 1em 0;margin:1em;border-radius:10px;box-shadow:3px 3px 5px 2px #ccc;">
  159. <p>TrueCrypt is software. Frankly, it&#8217;s incredibly great software. It&#8217;s large, complex and multi-platform. It has been painstakingly designed and implemented to provide the best security available anywhere. And it does. It is the best and most secure software modern computer science has been able to create. It is a miracle, and a gift, and it has been a labor of love we have toiled away, thanklessly for a decade, to provide to the world&#8230; for free.</p>
  160. <p>TrueCrypt is open source. Anyone could verify it, trust it, give back, contribute time, talent or money and help it to flourish. But no one has helped. Most just use it, question it and criticize it, while requiring it to be free, and complaining when it doesn&#8217;t work with this or that new system.</p>
  161. <p>After ten years of this mostly thankless and anonymous work, we&#8217;re tired. We&#8217;ve done our part. We have what we want. And we feel good about what we have created and freely given. Do we use it?&nbsp; Hell yes.&nbsp; As far as we know, TrueCrypt is utterly uncrackable, and plenty of real world experience, and ruthlessly still-protected drives, back up that belief.</p>
  162. <p>But hard drives have finally exceeded the traditional MBR partition table&#8217;s 32-bit sector count. 2.2 terabytes is not enough. So the world is moving to the GPT. But we&#8217;re not. We&#8217;re done. You&#8217;re on your own now. No more free lunch.</p>
  163. <p>We&#8217;re not bitter. Mostly we&#8217;re just tired and done with TrueCrypt. Like we wrote above, as far as we know today, it is a flawless expression of cryptographic software art. And we&#8217;re very proud of it. But TrueCrypt, which we love, has been an obligation hanging over our heads for so long that we&#8217;ve decided to not only shut it down, but to shoot it in the head. If you believe we&#8217;re not shooting blanks you may want to switch to something else. Our point is, now, finally, it&#8217;s on you, not us.</p>
  164. <p>Good luck with your NSA, CIA, and FBI.</p>
  165. </div>
  166. <div style="text-align:center;">Please also see <a href="http://bradkovach.com/2014/05/the-death-of-truecrypt-a-symptom-of-a-greater-problem/">Brad Kovach&#8217;s blog posting</a> about this topic. <i>Very useful</i>.</div>
  167. <p>/Steve.</p>
  168. ]]></content:encoded>
  169. <wfw:commentRss>http://steve.grc.com/2014/05/29/an-imagined-letter-from-the-truecrypt-developers/feed/</wfw:commentRss>
  170. <slash:comments>105</slash:comments>
  172. <media:content url="http://1.gravatar.com/avatar/a604d67a7804cad916465d435e73a55c?s=96&#38;d=monsterid&#38;r=G" medium="image">
  173. <media:title type="html">agilesynapse</media:title>
  174. </media:content>
  175. </item>
  176. <item>
  177. <title>Whither TrueCrypt?</title>
  178. <link>http://steve.grc.com/2014/05/28/whither-truecrypt/</link>
  179. <comments>http://steve.grc.com/2014/05/28/whither-truecrypt/#comments</comments>
  180. <pubDate>Wed, 28 May 2014 23:15:41 +0000</pubDate>
  181. <dc:creator><![CDATA[Steve Gibson]]></dc:creator>
  182. <category><![CDATA[Uncategorized]]></category>
  183.  
  184. <guid isPermaLink="false">http://steve.grc.com/?p=407</guid>
  185. <description><![CDATA[My guess is that the TrueCrypt self-takedown is going to turn out to be legitimate. We know NOTHING about the developers behind TrueCrypt. Research Professor Matthew Green, Johns Hopkins Cryptographer who recently helped to launch the TrueCrypt Audit, is currently &#8230; <a href="http://steve.grc.com/2014/05/28/whither-truecrypt/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
  186. <content:encoded><![CDATA[<p style="text-align:center;color:#900;font-size:18pt;">My guess is that the TrueCrypt self-takedown<br />
  187. is going to turn out to be legitimate.</p>
  188. <p><strong>We know NOTHING about the developers behind TrueCrypt.</strong></p>
  189. <p><a href="http://blog.cryptographyengineering.com/">Research Professor Matthew Green</a>, Johns Hopkins Cryptographer who recently helped to launch <a href="http://istruecryptauditedyet.com/">the TrueCrypt Audit</a>, is currently as clueless as anyone. But <a href="https://twitter.com/matthew_d_green">his recent tweets</a> indicate that he has come to the same conclusion that I have:</p>
  190. <div style="border:#000 1px solid;padding:1em 1em 0;margin:1em;border-radius:10px;box-shadow:3px 3px 5px 2px #ccc;">
  191. <ul>
  192. <li>I have no idea what&#8217;s up with the Truecrypt site, or what &#8216;security issues&#8217; they&#8217;re talking about.</li>
  193. <li>I sent an email to our contact at Truecrypt. I&#8217;m not holding my breath though.</li>
  194. <li>The sad thing is that after all this time I was just starting to like Truecrypt. I hope someone forks it if this is for real.</li>
  195. <li>The audit did not find anything &#8212; or rather, nothing that we haven&#8217;t already published.</li>
  196. <li>The anonymous Truecrypt dev team, from their submarine hideout. I emailed. No response. Takes a while for email to reach the sub.</li>
  197. <li>I think it unlikely that an unknown hacker (a) identified the Truecrypt devs, (b) stole their signing key, (c) hacked their site.</li>
  198. <li>Unlikely is not the same as impossible. So it&#8217;s *possible* that this whole thing is a hoax. I just doubt it.</li>
  199. <li>But more to the point, if the Truecrypt signing key was stolen &amp; and the TC devs can&#8217;t let us know &#8212; that&#8217;s reason enough to be cautious.</li>
  200. <li>Last I heard from Truecrypt: &#8220;We are looking forward to results of phase 2 of your audit. Thank you very much for all your efforts again!&#8221;</li>
  201. </ul>
  202. </div>
  203. <p>I checked out the cryptographic (Authenticode) certificate used to sign the last known authentic version (v7.1a) of TrueCrypt, signed on Feb. 7th, 2012:</p>
  204. <p style="text-align:center;"><a href="http://agilesynapse.files.wordpress.com/2014/05/tc-7-1a.png"><img id="i-416" class="size-full wp-image" src="http://agilesynapse.files.wordpress.com/2014/05/tc-7-1a.png?w=409" alt="Image" srcset="http://agilesynapse.files.wordpress.com/2014/05/tc-7-1a.png?w=409 409w, http://agilesynapse.files.wordpress.com/2014/05/tc-7-1a.png?w=129 129w, http://agilesynapse.files.wordpress.com/2014/05/tc-7-1a.png?w=258 258w, http://agilesynapse.files.wordpress.com/2014/05/tc-7-1a.png 419w" sizes="(max-width: 409px) 100vw, 409px" /></a></p>
  205. <p>You&#8217;ll notice that nine months after being used to sign the v7.1a Windows executable the signing certificate expired (on November 9th of 2012.)</p>
  206. <p>The just-created Windows executable version of TrueCrypt, v7.2, was signed on May 27th, 2014 with THIS certificate:</p>
  207. <p style="text-align:center;"><a href="http://agilesynapse.files.wordpress.com/2014/05/tc-7-2.png"><img id="i-422" class="size-full wp-image" src="http://agilesynapse.files.wordpress.com/2014/05/tc-7-2.png?w=409" alt="Image" srcset="http://agilesynapse.files.wordpress.com/2014/05/tc-7-2.png?w=409 409w, http://agilesynapse.files.wordpress.com/2014/05/tc-7-2.png?w=129 129w, http://agilesynapse.files.wordpress.com/2014/05/tc-7-2.png?w=258 258w, http://agilesynapse.files.wordpress.com/2014/05/tc-7-2.png 419w" sizes="(max-width: 409px) 100vw, 409px" /></a></p>
  208. <p>You&#8217;ll notice that the certificate which signed it was minted on August 24th of 2012, a few months before the <strong>previous</strong> certificate was due to expire, just like we&#8217;d expect, and also by the same CA (GlobalSign), though having a longer public key (4096 bits). This all exactly passes the smell test.</p>
  209. <p>In a comment below, Taylor Hornby of <a href="https://defuse.ca/">Defuse Security</a> noted that “The GPG signatures of the files also check out. The key used to sign them is the same as the one that was used to sign the 7.1a files I downloaded months ago.” So, again, this speaks of either a willful and deliberate act by the developers, or a rather stunning compromise of their own security. While, yes, the latter is possible, it seems much more likely, if also much less welcome, that TrueCrypt has been completely abandoned by its creators.</p>
  210. <p>So, given the scant evidence, I think it&#8217;s much more likely that the TrueCrypt team&nbsp;– whomever they are – legitimately created this updated Windows executable and other files which would imply that they also took down their long-running TrueCrypt site.</p>
  211. <p>Which, of course, leaves us asking why?&nbsp; We don&#8217;t know because we don&#8217;t know anything about them or their motives. They might be in Russia or China where Windows XP is still a big deal (with a more than 50% share) and personally annoyed with Microsoft for cutting off support for Windows XP.&nbsp; Or anything else.</p>
  212. <p>What&#8217;s creepy is that we may never know.</p>
  213. <p>/Steve.</p>
  214. ]]></content:encoded>
  215. <wfw:commentRss>http://steve.grc.com/2014/05/28/whither-truecrypt/feed/</wfw:commentRss>
  216. <slash:comments>191</slash:comments>
  218. <media:content url="http://1.gravatar.com/avatar/a604d67a7804cad916465d435e73a55c?s=96&#38;d=monsterid&#38;r=G" medium="image">
  219. <media:title type="html">agilesynapse</media:title>
  220. </media:content>
  221.  
  222. <media:content url="http://agilesynapse.files.wordpress.com/2014/05/tc-7-1a.png?w=409" medium="image">
  223. <media:title type="html">Image</media:title>
  224. </media:content>
  225.  
  226. <media:content url="http://agilesynapse.files.wordpress.com/2014/05/tc-7-2.png?w=409" medium="image">
  227. <media:title type="html">Image</media:title>
  228. </media:content>
  229. </item>
  230. <item>
  231. <title>A quick mitigation for Internet Explorer&#8217;s new 0-day vulnerability</title>
  232. <link>http://steve.grc.com/2014/04/28/a-quick-mitigation-for-internet-explorers-new-0-day-vulnerability/</link>
  233. <comments>http://steve.grc.com/2014/04/28/a-quick-mitigation-for-internet-explorers-new-0-day-vulnerability/#comments</comments>
  234. <pubDate>Mon, 28 Apr 2014 16:32:14 +0000</pubDate>
  235. <dc:creator><![CDATA[Steve Gibson]]></dc:creator>
  236. <category><![CDATA[Uncategorized]]></category>
  237.  
  238. <guid isPermaLink="false">http://steve.grc.com/?p=343</guid>
  239. <description><![CDATA[The Internet industry press has been milking the news of the end of Windows XP support for much more than it&#8217;s worth. Now, over the weekend, we get news of another, in a continuing series of, (0-day) flaws in Internet &#8230; <a href="http://steve.grc.com/2014/04/28/a-quick-mitigation-for-internet-explorers-new-0-day-vulnerability/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
  240. <content:encoded><![CDATA[<p>The Internet industry press has been milking the news of the end of Windows XP support for much more than it&#8217;s worth. Now, over the weekend, we get news of another, in a continuing series of, (0-day) flaws in Internet Explorer.  (Oh My God! It&#8217;s the XPocalypse!!)</p>
  241. <p>Or maybe not quite yet.</p>
  242. <p style="color:#900;text-align:center;"><strong>May 1st, 2014: Microsoft has decided to patch everyone&#8217;s<br />
  243. versions of Internet Explorer v6 through v11&#8230; even on XP.<br />
  244. So nothing changes yet.  Stay tuned. (And update your IE&#8217;s!)</strong></p>
  245. <p>Web browsers are growing incredibly complex. It&#8217;s pretty clear that they will be our next-generation operating platforms. And as the last annual &#8220;<a title="2014 Pwn2Own Recap" href="http://www.pwn2own.com/2014/03/pwn2own-2014-recap/">Pwn2Own</a>&#8221; contest showed, <strong>none</strong> of them can currently withstand the focused attention of skilled and determined attackers, especially when some prize money is dangled on the other side of the finish line.</p>
  246. <p>With most recent exploits, the path to exploitation is convoluted and complex and this one is no exception. In this case it depends upon encountering malicious Web content with IE&#8217;s ActiveScripting and ActiveX enabled (which is the default in both cases). That will load an Adobe SWF (Shockwave FLASH) file which first prepares the machine for exploitation, then uses JavaScript against the vulnerable version of IE (presently <em>all</em> versions of IE) to exploit a subtle flaw in the age-old and long-ago deprecated VML (vector markup language) rendering library. (Which is, nonetheless, still hanging around &#8220;just in case.&#8221;)</p>
  247. <p>To immediately protect any use of Internet Explorer – yes, even on creaky old WinXP (the XPocalypse has been delayed):  You must first open a command prompt window with administrative privileges. This is done by right-clicking on the Command Prompt icon in the start menu and selecting &#8220;Run As Administrator.&#8221; Commands issued within this window will have the privilege required to make system level changes.</p>
  248. <p>32-bit systems only require the first command. But since 64-bit systems have both a 32-bit and 64-bit version of the vulnerable file, both commands must be used with them:</p>
  249. <pre>regsvr32 -u "%CommonProgramFiles%\Microsoft Shared\VGX\vgx.dll"
  250. regsvr32 -u "%CommonProgramFiles(x86)%\Microsoft Shared\VGX\vgx.dll"</pre>
  251. <p>These commands unregister (-u) the VML renderer, making it inaccessible to the exploit attempt.  Your IE browser will no longer be able to render vector markup language content, but it&#8217;s been unused on the web for many years.</p>
  252. <p>You can perform a &#8220;before and after&#8221; test to confirm that VML rendering has been disabled with this simple VML rendering of an office layout: <a href="http://www.vmlmaker.com/gallery/visio/office_layout.htm">http://www.vmlmaker.com/gallery/visio/office_layout.htm</a>. <span style="text-decoration:underline;">The proper response is a BLANK PAGE</span>. If you receive a notice that &#8220;A VML capable browser is required&#8230;&#8221; you must add the vmlmaker.com domain to IE&#8217;s &#8220;Compatibility View&#8221; for the test to function properly. This is done under the settings menu.</p>
  253. <p style="border:#888 1px solid;padding:.5em 1em;">Note: An additional test can be performed by searching the Windows registry (search: Data with &#8220;Match whole strings only&#8221; disabled) for references to vgx.dll. If it is found showing its location as the &#8220;Default&#8221; data of an &#8220;InprocServer32&#8221; key, then it is still registered and available.</p>
  254. <p style="text-align:left;">You can confidently leave things this way.. since you are never going to need VML and, as this circus shows, we&#8217;re all a lot better off without it!</p>
  255. <p>(My most recent work: <a title="An Evaluation of the Effectiveness of Chrome's CRLSets" href="https://www.grc.com/revocation/crlsets.htm">An Evaluation of the Effectiveness of Chrome&#8217;s CRLSets</a>.)</p>
  256. <p>/Steve.</p>
  257. ]]></content:encoded>
  258. <wfw:commentRss>http://steve.grc.com/2014/04/28/a-quick-mitigation-for-internet-explorers-new-0-day-vulnerability/feed/</wfw:commentRss>
  259. <slash:comments>106</slash:comments>
  261. <media:content url="http://1.gravatar.com/avatar/a604d67a7804cad916465d435e73a55c?s=96&#38;d=monsterid&#38;r=G" medium="image">
  262. <media:title type="html">agilesynapse</media:title>
  263. </media:content>
  264. </item>
  265. <item>
  266. <title>The Lesson of Lavabit</title>
  267. <link>http://steve.grc.com/2013/08/08/the-lesson-of-lavabit/</link>
  268. <comments>http://steve.grc.com/2013/08/08/the-lesson-of-lavabit/#comments</comments>
  269. <pubDate>Thu, 08 Aug 2013 20:49:40 +0000</pubDate>
  270. <dc:creator><![CDATA[Steve Gibson]]></dc:creator>
  271. <category><![CDATA[Uncategorized]]></category>
  272.  
  273. <guid isPermaLink="false">http://steve.grc.com/?p=281</guid>
  274. <description><![CDATA[An implication of undeliverable security painted a bullseye&#8230;Post&#8217;s Permalink On Thursday, August 8th, Ladar Levison, the owner and operator of the semi-secure Lavabit.com eMail system, shut down his nearly ten year old service rather than be forced to continue to &#8230; <a href="http://steve.grc.com/2013/08/08/the-lesson-of-lavabit/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
  275. <content:encoded><![CDATA[<p><span style="display:block;text-align:right;"><span style="float:left;"><em><strong>An implication of undeliverable security painted a bullseye&#8230;</strong></em></span><a href="http://wp.me/pV3mA-4x"><span style="font-size:smaller;">Post&#8217;s Permalink</span></a></span></p>
  276. <p>On Thursday, August 8th, Ladar Levison, the owner and operator of the semi-secure Lavabit.com eMail system, shut down his nearly ten year old service rather than be forced to continue to comply with United States law enforcement demands for the disclosure of personal and private information belonging to his service&#8217;s clients. The <strong><a title="Lavabit home page" href="http://lavabit.com/">Lavabit web site</a></strong> now simply displays this notice:</p>
  277. <div style="background:#eee;padding:1em;margin:1em;">
  278. <p>My Fellow Users,</p>
  279. <p>I have been forced to make a difficult decision: to become complicit in crimes against the American people or walk away from nearly ten years of hard work by shutting down Lavabit. After significant soul searching, I have decided to suspend operations. I wish that I could legally share with you the events that led to my decision. I cannot. I feel you deserve to know what’s going on&#8211;the first amendment is supposed to guarantee me the freedom to speak out in situations like this. Unfortunately, Congress has passed laws that say otherwise. As things currently stand, I cannot share my experiences over the last six weeks, even though I have twice made the appropriate requests.</p>
  280. <p>What’s going to happen now? We’ve already started preparing the paperwork needed to continue to fight for the Constitution in the Fourth Circuit Court of Appeals. A favorable decision would allow me resurrect Lavabit as an American company.</p>
  281. <p>This experience has taught me one very important lesson: without congressional action or a strong judicial precedent, I would _strongly_ recommend against anyone trusting their private data to a company with physical ties to the United States.</p>
  282. <p>Sincerely,<br />
  283. Ladar Levison<br />
  284. Owner and Operator, Lavabit LLC</p>
  285. <p>Defending the constitution is expensive! Help us by donating to the Lavabit Legal Defense Fund <strong><a href="https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&amp;hosted_button_id=7BCR4A5W9PNN4">here</a></strong>.</p>
  286. </div>
  287. <p>What is the lesson of Lavabit?</p>
  288. <p>When news first surfaced about Edward Snowden&#8217;s presumptive use of Lavabit&#8217;s eMail service for his eMail communication the assumption was that it was somehow &#8220;secure.&#8221; So I researched the nature of the service that was being offered, and I was not impressed. The trouble was, it was making a lot of noise about security, but as an eMail store-and-forward service it didn&#8217;t (and couldn&#8217;t) really do anything that was very useful from a security standpoint: Ladar had arranged to encrypt and store incoming eMail to a user&#8217;s inbox in such a fashion that his service could not then immediately decrypt the eMail. It would not be until the user logged in that the Lavabit servers would be able to derive the decryption key in order to forward the then decrypted eMail to the user.</p>
  289. <p>As you can see, while this did offer somewhat useful encryption of data-at-rest, it didn&#8217;t actually offer his users any real protection because both incoming and outgoing eMail would necessarily be transmitted in the clear.</p>
  290. <p>This architecture would, therefore, inherently expose the Lavabit service, its servers, its owners, and thus its users&#8217; data to law enforcement demands. Which, it seems clear, is exactly what happened. Ladar made his service a target by offering &#8220;security&#8221; that wasn&#8217;t actually secure. (And how very wrong is it that he cannot even share the exact nature of the demands that were made upon him?!)</p>
  291. <p><strong>I am impressed</strong> that Ladar chose to shutdown his service rather than continue to promise something that he now unequivocally knew was no longer secure in the face of law enforcement&#8217;s quasi-legal incursions. It would have probably been better if he hadn&#8217;t attempted to offer security that was beyond his ability to provide.</p>
  292. <p>During my weekly <a href="http://twit.tv/sn"><strong>Security Now! podcast with Leo Laporte</strong></a>, we use the acronym &#8220;TNO&#8221; (Trust No One) to refer to any system where readily available cryptographic technology is properly employed in such a fashion that it is not necessary to trust the behavior of any third party. Unfortunately, without going to extraordinary lengths (e.g. S/MIME, PGP, GnuPG, etc.), today&#8217;s eMail technology is resistant to the TNO principle.</p>
  293. <p>In coming weeks our Security Now! podcast will be delving deeply into the ways and means of producing true TNO eMail security.</p>
  294. <p><img alt="Steve's Sig" src="http://www.grc.com/image/smg-sig2.gif" /></p>
  295. ]]></content:encoded>
  296. <wfw:commentRss>http://steve.grc.com/2013/08/08/the-lesson-of-lavabit/feed/</wfw:commentRss>
  297. <slash:comments>230</slash:comments>
  299. <media:content url="http://1.gravatar.com/avatar/a604d67a7804cad916465d435e73a55c?s=96&#38;d=monsterid&#38;r=G" medium="image">
  300. <media:title type="html">agilesynapse</media:title>
  301. </media:content>
  302.  
  303. <media:content url="http://www.grc.com/image/smg-sig2.gif" medium="image">
  304. <media:title type="html">Steve&#039;s Sig</media:title>
  305. </media:content>
  306. </item>
  307. <item>
  308. <title>IronMan 3 was &#8220;Unbelievable&#8221;&#8230; but not in a good way.</title>
  309. <link>http://steve.grc.com/2013/05/04/ironman-3-was-unbelievable-but-not-in-a-good-way/</link>
  310. <comments>http://steve.grc.com/2013/05/04/ironman-3-was-unbelievable-but-not-in-a-good-way/#comments</comments>
  311. <pubDate>Sat, 04 May 2013 18:16:27 +0000</pubDate>
  312. <dc:creator><![CDATA[Steve Gibson]]></dc:creator>
  313. <category><![CDATA[Uncategorized]]></category>
  314. <category><![CDATA[IronMan 3]]></category>
  315. <category><![CDATA[Movie Review]]></category>
  316. <category><![CDATA[Science Fiction]]></category>
  317. <category><![CDATA[Summer 2013]]></category>
  318.  
  319. <guid isPermaLink="false">http://steve.grc.com/?p=276</guid>
  320. <description><![CDATA[My two-cent take on IronMan 3: This was a Disney/Marvel collaboration. Perhaps one problem was that it was too much Disney and insufficient Marvel. The thing I was conscious of at many points throughout the movie, was that in ridiculously &#8230; <a href="http://steve.grc.com/2013/05/04/ironman-3-was-unbelievable-but-not-in-a-good-way/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
  321. <content:encoded><![CDATA[<p>My two-cent take on IronMan 3:</p>
  322. <p>This was a Disney/Marvel collaboration. Perhaps one problem was that it was too much Disney and insufficient Marvel.</p>
  323. <p>The thing I was conscious of at many points throughout the movie, was that in ridiculously violent fights between unarmored and unprotected simple flesh and blood humans&#8230; no one gets hurt. In Road Runner cartoons, when the anvil flattens the Coyote, it&#8217;s quite funny due to its ludicrous overstatement. But the real parts of a movie involving humans &#8212; which are intended to be believable &#8212; really need to remain believable&#8230; or it&#8217;s asking too much from a mature audience.</p>
  324. <p>As a Science Fiction lover, I am more than willing to suspend my disbelief for the sake of immersion into a new idea. I loved the first IronMan, and have watched it many times. So I will gleefully imbue a robotic suit with any levels of strength and power the story may require. That&#8217;s fine. Bring it on. Thrill me. But I know the limitations of an unaided human body. We all have one. And what I saw far too much of, against human flesh, was a level of coyote-flattening violence that was utter nonsense.</p>
  325. <p>Despite the fact that I have no doubt IronMan 3 will break US domestic box office records, as it already has overseas, I think that &#8220;Oblivion&#8221; was the far better movie so far this summer.</p>
  326. <p>/Steve. (@SGgrc and <a href="http://www.grc.com" rel="nofollow">http://www.grc.com</a>)</p>
  327. ]]></content:encoded>
  328. <wfw:commentRss>http://steve.grc.com/2013/05/04/ironman-3-was-unbelievable-but-not-in-a-good-way/feed/</wfw:commentRss>
  329. <slash:comments>52</slash:comments>
  331. <media:content url="http://1.gravatar.com/avatar/a604d67a7804cad916465d435e73a55c?s=96&#38;d=monsterid&#38;r=G" medium="image">
  332. <media:title type="html">agilesynapse</media:title>
  333. </media:content>
  334. </item>
  335. <item>
  336. <title>Reverse Engineering RSA&#8217;s &#8220;Statement&#8221;</title>
  337. <link>http://steve.grc.com/2011/03/19/reverse-engineering-rsas-statement/</link>
  338. <comments>http://steve.grc.com/2011/03/19/reverse-engineering-rsas-statement/#comments</comments>
  339. <pubDate>Sat, 19 Mar 2011 20:11:03 +0000</pubDate>
  340. <dc:creator><![CDATA[Steve Gibson]]></dc:creator>
  341. <category><![CDATA[Uncategorized]]></category>
  342.  
  343. <guid isPermaLink="false">http://steve.grc.com/?p=245</guid>
  344. <description><![CDATA[Responsible Disclosure? &#160;Ummm, not so much&#8230;Sharable Shortlink On March 17th, 2011, Art Coviello, RSA Security&#8216;s Executive Chairman, posted a disturbingly murky statement on their website disclosing their discovery of an “APT” (Advanced Persistent Threat). In other words, they discovered that &#8230; <a href="http://steve.grc.com/2011/03/19/reverse-engineering-rsas-statement/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
  345. <content:encoded><![CDATA[<p><em><span style="display:block;text-align:right;"><em><strong><span style="color:#993300;"><span style="float:left;"><span style="font-size:larger;">Responsible Disclosure? &nbsp;Ummm, not so much&#8230;</span></span></span></strong></em><a href="http://wp.me/pV3mA-3X"><span style="font-size:smaller;">Sharable Shortlink</span></a></span></em></p>
  346. <p>On March 17<sup>th</sup>, 2011, Art Coviello, <a href="http://www.rsa.com">RSA Security</a>&#8216;s Executive Chairman, posted <a href="http://www.rsa.com/node.aspx?id=3872">a disturbingly murky statement</a> on their website disclosing their discovery of an “APT” (Advanced Persistent Threat). In other words, they discovered that bad guys had been rummaging around within their internal network for some time (persistent) and had managed to penetrate one of their most sensitive and secret databases. &nbsp;Here is the most relevant piece of Art Coviello&#8217;s disclosure (<a href="http://www.rsa.com/node.aspx?id=3872">you can find the whole piece here</a>):</p>
  347. <div style="margin-bottom:1em;color:#006000;background-color:#f0fff0;border:2px solid #008000;padding:.5em;">[&#8230;] Our investigation also revealed that the attack resulted in certain information being extracted from RSA&#8217;s systems. Some of that information is specifically related to RSA&#8217;s SecurID two-factor authentication products. While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack. We are very actively communicating this situation to RSA customers and providing immediate steps for them to take to strengthen their SecurID implementations. [&#8230;]</div>
  348. <p>As you can see, it would have been difficult for any bureaucrat to be <em><strong>less</strong></em> clear about what they know. But science is science, and the simple realities of what must be going on doesn&#8217;t accommodate much bureaucratic wiggle-room:</p>
  349. <p>RSA&#8217;s SecureID devices are known to be designed around a cipher keyed with a 64-bit secret.  The 64-bit secret is used to encrypt a realtime counter which generates an effective 22-bit value.  While this is not many bits of time, the clock is incremented slowly, only once every 30 or 60 seconds, so 22-bits (4,194,304 values) is sufficient to outlive the expected life of the device and the timer would never be expected to wrap around.</p>
  350. <div data-shortcode="caption" id="attachment_249" style="width: 510px" class="wp-caption aligncenter"><a href="http://agilesynapse.files.wordpress.com/2011/03/rsasecureidtoken.jpg"><img aria-describedby="caption-attachment-249" data-attachment-id="249" data-permalink="http://steve.grc.com/2011/03/19/reverse-engineering-rsas-statement/rsasecureidtoken/" data-orig-file="https://agilesynapse.files.wordpress.com/2011/03/rsasecureidtoken.jpg" data-orig-size="500,225" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;}" data-image-title="RSA SecureID Token" data-image-description="" data-medium-file="https://agilesynapse.files.wordpress.com/2011/03/rsasecureidtoken.jpg?w=300" data-large-file="https://agilesynapse.files.wordpress.com/2011/03/rsasecureidtoken.jpg?w=500" class="size-full wp-image-249" title="RSA SecureID Token" src="http://agilesynapse.files.wordpress.com/2011/03/rsasecureidtoken.jpg?w=640" alt="RSA SecureID Token" srcset="http://agilesynapse.files.wordpress.com/2011/03/rsasecureidtoken.jpg 500w, http://agilesynapse.files.wordpress.com/2011/03/rsasecureidtoken.jpg?w=150 150w, http://agilesynapse.files.wordpress.com/2011/03/rsasecureidtoken.jpg?w=300 300w" sizes="(max-width: 500px) 100vw, 500px"   /></a><p id="caption-attachment-249" class="wp-caption-text">One of several forms of the RSA SecurID Token</p></div>
  351. <p>Each SecureID has an external serial number (printed on the back) that is used to identify and register it with an authentication service. &nbsp;Hopefully, there is no &#8220;algorithm&#8221; of any sort for determining the internal secret key from the device&#8217;s serial number, since the discovery of such an algorithm would instantly kill the security of the entire system.</p>
  352. <p>In the absence of a mapping algorithm, at the time of manufacture individual SecurID devices would be assigned a secret internal random or pseudo-random 64-bit key and a database would be maintained to forever map the device&#8217;s externally visible serial number to its internal secret 64-bit key.</p>
  353. <p>This public-serial-number-to-secret-key mapping database then becomes &#8220;the keys to the kingdom&#8221;.  It is RSA&#8217;s biggest secret to keep, since a full or partial disclosure of the database would potentially allow attackers to determine a device&#8217;s current and future display values and would therefore, of course, break any authentication protection.</p>
  354. <p>To carry out a successful attack, an attacker would need to obtain its target device&#8217;s public serial number as well as one or more current output samples, at a known time, to determine the current state of the device&#8217;s 22-bit realtime clock. From that point on, an attacker could reliably determine the device&#8217;s output at any time in the future.</p>
  355. <p>What can be deduced from what (little) RSA has disclosed?</p>
  356. <ul>
  357. <li>If &#8220;the keys to the kingdom&#8221;—the public serial number to secret key mapping database—had <span style="text-decoration:underline;"><strong>NOT</strong></span> been compromised, there would be <em><strong>zero</strong></em> danger to users of RSA&#8217;s SecurIDs. &nbsp;But we know at least that the danger is <em><strong>not</strong></em> zero. &nbsp;<em><strong>Therefore, the most reasonable conclusion to reach is that RSA believes that at least some of &nbsp;&#8220;the keys to the kingdom&#8221; have been compromised.</strong></em> (Because that&#8217;s their system&#8217;s only real vulnerability.)</br></br></li>
  358. <li>Users of SecurID, and other multifactor authentication systems, typically do not provide the device&#8217;s public serial number when they are using it for authentication &#8230; though neither is that number intended to be kept secret (since it is printed on the back of every device.) &nbsp;This means that an attacker would need to either have brief physical access to a device to obtain its serial number (which would also presumably allow them to obtain a few output samples to determine the clock counter&#8217;s current realtime position), or also have compromised RSA&#8217;s authentication account registration database which presumably maps user accounts to their device&#8217;s SecurID serial number. &nbsp;Unless RSA discloses more, we won&#8217;t know how much more than the secret key mapping database may have been compromised. &nbsp;Thus, it&#8217;s not possible to assemble a comprehensive threat model.</br></br></li>
  359. <li>RSA may not want to do the responsible thing because it would be <em><strong>very</strong></em> expensive for them<strong>&#8230;</strong> but given the <em><strong>only deductions possible</strong></em> from what little RSA has said in light of the technology, <span style="color:#993300;"><em><strong>any company using RSA SecurID tokens should consider them completely compromised and should insist upon their immediate replacement.</strong></em></span></li>
  360. </ul>
  361. <p>RSA is understandably embarrassed. &nbsp;And mistakes do happen. &nbsp;If employees of a security company are using today&#8217;s incredibly insecure desktop toy operating systems, bad guys <em><strong>are</strong></em> going to be able to find a way to penetrate even the most carefully guarded connected networks.</p>
  362. <p>RSA therefore needs to step up to the plate and take responsibility for what has happened. That means recalling <em>every single SecurID device</em> and replacing them all. &nbsp;No company can consider RSA&#8217;s existing deployed SecurID devices to be secure.</p>
  363. <p>You may <a href="http://steve.grc.com/2011/03/19/reverse-engineering-rsas-statement/">CLICK THIS LINK</a> to view this blog posting by itself so you can see replies and add your own.</p>
  364. <p><img src="http://www.grc.com/image/smg-sig2.gif" alt="Steve's Sig" /></p>
  365. ]]></content:encoded>
  366. <wfw:commentRss>http://steve.grc.com/2011/03/19/reverse-engineering-rsas-statement/feed/</wfw:commentRss>
  367. <slash:comments>126</slash:comments>
  369. <media:content url="http://1.gravatar.com/avatar/a604d67a7804cad916465d435e73a55c?s=96&#38;d=monsterid&#38;r=G" medium="image">
  370. <media:title type="html">agilesynapse</media:title>
  371. </media:content>
  372.  
  373. <media:content url="http://agilesynapse.files.wordpress.com/2011/03/rsasecureidtoken.jpg" medium="image">
  374. <media:title type="html">RSA SecureID Token</media:title>
  375. </media:content>
  376.  
  377. <media:content url="http://www.grc.com/image/smg-sig2.gif" medium="image">
  378. <media:title type="html">Steve&#039;s Sig</media:title>
  379. </media:content>
  380. </item>
  381. </channel>
  382. </rss>
  383.  

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

  1. Download the "valid RSS" banner.

  2. Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)

  3. Add this HTML to your page (change the image src attribute if necessary):

If you would like to create a text link instead, here is the URL you can use:

http://www.feedvalidator.org/check.cgi?url=http%3A//feeds.feedburner.com/SteveGibsonsBlog

Home · About · News · Docs · Terms

 
Copyright © 2002-9 Sam Ruby, Mark Pilgrim, Joseph Walton, and Phil Ringnalda