<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta name=Generator content="Microsoft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><title>FW: Android app signing problems -- it's even worse than I imagined</title><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Forwarding this from the ABA InfoSec listserv.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Information Security Committee Discussion [mailto:ST-ISC@MAIL.AMERICANBAR.ORG] <b>On Behalf Of </b>Robert R. Jueneman<br><b>Sent:</b> Friday, September 28, 2012 12:55 PM<br><b>To:</b> ST-ISC@MAIL.AMERICANBAR.ORG<br><b>Subject:</b> FW: Android app signing problems -- it's even worse than I imagined<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-family:"Calibri","sans-serif"'>First of all, I guess I should apologize for explicitly mentioning my company’s products in my last e-mail. I did so only to be specific, and not leave people guessing. Mea culpa.<br></span><br><span style='font-family:"Calibri","sans-serif"'>I would like to think that I had a pretty good imagination, but the code-signing process that is documented for Android apps at <a href="http://developer.android.com/tools/publishing/app-signing.html#cert#cert">http://developer.android.com/tools/publishing/app-signing.html#cert#cert</a> <<a href="http://developer.android.com/tools/publishing/app-signing.html#cert#cert">http://developer.android.com/tools/publishing/app-signing.html#cert#cert</a>> boggles my mind.<br></span><br><span style='font-family:"Calibri","sans-serif"'>Chief among my complaints:<br></span><br><span style='font-family:"Calibri","sans-serif"'>1. “You can use self-signed certificates to sign your applications. No certificate authority is needed.” So that means that you can sign your app as google.com, microsoft.com, dod.gov, fbi.gov, or whatever you choose, and no one will ever be the wiser.<br></span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br></span><span style='font-family:"Calibri","sans-serif"'>2. “The system tests a signer certificate's expiration date only at install time. If an application's signer certificate expires after the application is installed, the application will continue to function normally.” So if malware infects your machine and alters one of your apps after installation, you will have no way of knowing about it.<br></span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br></span><span style='font-family:"Calibri","sans-serif"'>3. Since self-signed certificates are allowed, it is not surprising that CRLs are not required to be supported. So if an incident such as the recent Adobe compromise occurs, the user will have no automatic way of knowing about it.<br></span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br></span><span style='font-family:"Calibri","sans-serif"'>4. If you use the Android Keytool for generating the signing key, a default key of 1024 bits is used. This is clearly inadequate. Only DSA and RSA are supported, and not ECDSA. Worse yet, only MD5 seems to be supported for the signing algorithm, although SHA-1 is supported for the digest algorithm.<br></span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br></span><span style='font-family:"Calibri","sans-serif"'>5. Keys are generated in software, and stored under password protection.<br></span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br></span><span style='font-family:"Calibri","sans-serif"'>This entire process seems to have been dreamed up around 1990 or earlier. It certainly doesn’t reflect current best practices. And given the extent to which adverse governments and other hostile forces seem to be attacking our cyber security, I think this is regrettable, to say the least – at least if you are developing anything more important than Angry Birds.<br></span><br><span style='font-family:"Calibri","sans-serif"'>Bob<br></span><span style='color:#1F497D'><br></span>______________________________________<o:p></o:p></p><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Information Security Committee Discussion [mailto:ST-ISC@MAIL.AMERICANBAR.ORG] <b>On Behalf Of </b>Robert R. Jueneman<br><b>Sent:</b> Friday, September 28, 2012 11:13 AM<br><b>To:</b> ST-ISC@MAIL.AMERICANBAR.ORG<br><b>Subject:</b> Code signing certificate problems and issues.<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-family:"Calibri","sans-serif"'>This is a very timely reminder of how important it is to do this right. Adobe has repeatedly been shown to be either uncaring or uninformed about security, and this is just the latest incident. But the fact that allegedly external attackers were able to penetrate their server should be a wake-up call for any of us who are generating code that needs to be signed.<br><br>Here are my recommendations for how to do this using my company’s (SPYRUS) components, in order to minimize the risk: <br> <br>1. Build an operational key signing application from scratch (so as to be sure it isn’t infected). This needs to be done in a secure area, using components loaded from DVDs, and not from the Internet. <br><br>2. That key signing application should then be installed on a SPYRUS Secure Pocket Drive hardware device in Read-Only mode, so that you will always have a fresh, clean image whenever you need to sign something. You can then plug the Secure Pocket Drive into any available laptop or desktop machine — it won’t even access the computer’s hard drive, so no viruses could be loaded or propagated. Nonetheless, that machine should not be connected to the Internet, or even to the company’s internal network, as we have seen from the Adobe example.<br><br>3. The private signature key or keys should be created on a SPYRUS Digital Attaché, so that they can never be extracted. The public keys can be extracted and sent off to Symantec or other signing service to obtain certificates.<br><br>4. Three trusted employees should get together in a secure room to sign any code segments. One person should have the logon PIN for the Secure Pocket Drive, one should have the Digital Attaché PIN, and one should have the Windows application logon PIN.<br><br>5. These PINs should be recorded and sealed in three separate envelopes for back-up purposes, and kept in a bank vault to which only the corporate officers have access – preferably under at least two-person control.<br><br>6. The Secure Pocket Drive and Digital Attaché hardware devices should be kept in a locked container when not in use.<br> <br>Now, Adobe is apparently in the process of revoking their compromised code signing key, but based on my internal investigations, it isn’t at all clear just how that will solve the problem, if the bogus app has already been installed.<br><br>I would love to have someone either confirm or deny my present understanding, but on Windows XP, it doesn’t appear that ANY checking of the signing certificate is done after the application is first installed. Even then, it is not obvious that lower level DLLs are being validated, ever.<br><br>On Vista and newer platforms, once an application has been installed, system services and drivers, especially on 32-bit versions, are apparently not checked, ever again. On 64-bit versions, drivers signed by Microsoft (not VeriSign or Symantec) are needed for most applications to be installed. But again, once they are installed, it is again not at all clear that platform systems services are checked for signatures.<br><br>And if all of that seems pretty fuzzy, the situation with respect to certificates that simply expire, or are revoked, is even less clear. <br><br>From what we have been able to determine, the inclusion of a CRL distribution point in the certificate is optional, and without CRLs, the user or application would have no way of knowing whether the certificate had been revoked, or not. More seriously, if the certificate simply expires, perhaps because the code-signing organization only purchased a 1, 2, or 3 year certificate and didn’t renew it (which brings up yet another set of questions), then presumably no CRLs would be available in any case.<br><br>To make matters worse, the code-signing scripts have an option for generating a secure time-stamp, and if that time-stamp hasn’t been modified, that application is still considered “good”. So that provides protection against installing bad applications once the certificate has been revoked, which may take a week or more, but it does nothing at all to protect against attacks that were only recently discovered. In other words, once the horse is out of the barn, the user is on their own.<br><br>Unfortunately, in my opinion, the situation with Google and Android is even worse. Google is REQUIRING that their apps be signed with a certificate with a 25-year validity period, in order to be eligible for distribution via Google Play. Now, in my judgment that is just a ridiculously long time. Not only does it exceed the current recommendations from NIST for RSA-2048 keys, which should be deprecated for use after 2030, but it doesn’t take into account the life expectancy of most applications, and particularly those on devices as volatile as a cell phone or tablet. Think about it — 25 years would take us back to Windows 3.0 or earlier. Now who in their right mind would still be using apps that came out that long ago?<br><br>More importantly, 25 years is simply too long a time-period from a risk-management and corporate turn-over perspective. People will come and go, and even entire companies may turn over in that amount of time. So from my perspective, apps and the certificates used to certify them should have a life expectancy of about 5 years, and after about 3 years the organization should get a new certificate, and start using that new key to sign those apps.<br><br>I think it is time for for the ISC to rethink the PKI model as it applies to code-signing applications, as opposed to the traditional nonrepudiation of documents.<br><br>Bob</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><div class=MsoNormal align=center style='text-align:center'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><hr size=3 width="95%" align=center></span></div><p class=MsoNormal style='margin-bottom:12.0pt'><b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>From: </span></b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Hoyt L Kesterson II <<a href="hoyt.kesterson@TERRAVERDESERVICES.COM">hoyt.kesterson@TERRAVERDESERVICES.COM</a>><br><b>Reply-To: </b>Hoyt L Kesterson II <<a href="hoyt.kesterson@TERRAVERDESERVICES.COM">hoyt.kesterson@TERRAVERDESERVICES.COM</a>><br><b>Date: </b>Thu, 27 Sep 2012 22:01:28 -0700<br><b>To: </b>ABA <<a href="ST-ISC@MAIL.AMERICANBAR.ORG">ST-ISC@MAIL.AMERICANBAR.ORG</a>><br><b>Subject: </b>Re: Move along, nothing to see,<br><br>One doesn't have to break into an HSM to get to the keys (I'm assuming a function this important is done with a hardware security module doing the signing); one only has to fool the HSM into thinking you're an authorized user of its services.<br><br>Ars Technica also has an article <<a href="http://arstechnica.com/security/2012/09/adobe-to-revoke-crypto-key-abused-to-sign-5000-malware-apps/">http://arstechnica.com/security/2012/09/adobe-to-revoke-crypto-key-abused-to-sign-5000-malware-apps/</a>> on this.<br><br> hoyt<br><br><br>On 27 Sep 2012, at 9:55 PM, Steven W. Teppler wrote:</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Adobe signing cert problems...<br><br><a href="http://www.theregister.co.uk/2012/09/27/adobe_cert_revoked/">http://www.theregister.co.uk/2012/09/27/adobe_cert_revoked/</a><br><br>Sent from my iPad<br><br><br></span><o:p></o:p></p><p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div></body></html>