<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>+1</div><div>Good input!<br><br>Sent from my iPhone</div><div><br>On 4 Nov 2014, at 21:54, Jason Haddix <<a href="mailto:jason.haddix@owasp.org">jason.haddix@owasp.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div><div><br></div><div>This was posted from Brad Hill (Sec Engineer at Facebook) to our MTT mailing list, pasted verbatim:</div><div><br></div><div>"I won't be able to make the call, but wanted to provide some documented feedback on the topic.</div><div><br></div><div>As currently written, multiple experts have expressed serious concerns that M10 actually presents a sound security practice and reasonable goals.  Obfuscation systems that are practical to deploy for current mobile app platforms can at best marginally increase the cost of attacking an application.  At worst, they create a false sense of security.  For sufficiently valuable secrets, determined attackers will find ways to bypass any obfuscation possible with current techniques.  Encouraging the idea that these are meaningful and effective protections therefore propagates mistaken software architectures that promise things to users they cannot deliver.  The recent attack against users of the Snapchat service where malicious or insecure clients used API keys extracted from the obfuscated genuine app is a great example of the kind of risks this bad advice presents.</div><div><br></div><div>For client-server architectures that distribute identical binaries to all clients, we have known the appropriate security practice for decades: do not put secrets in the source code or binary.  (whether those secrets are cryptographic keys or algorithms)  It is true that this makes distributed systems with properties that many developers want either difficult or impossible to build. (e.g. API endpoints that can remotely determine that they are being called by "authorized" or "genuine" client software only)  But if these are serious problems, they deserve serious solutions - we shouldn't reduce the necessary market pressure on mobile platform and app store vendors to provide provisioning methods with different security properties by selling snake oil to developers who may not know better.</div><div><br></div><div>I think there are two salvageable categories that can be matched to the data:</div><div><br></div><div>1) Missing Anti-exploit Protections.  These are measures like ASLR that increase the cost of exploitation from outside of the application's security boundaries.</div><div>2) Embedded Shared Secrets.  Yes, the data will show that many apps are vulnerable because of this.  The answer is simple: don't embed secrets in a shared distribution.</div><div><br></div><div>This anti-jailbreak, anti-debug, anti-RE, secret obfuscation stuff has to stop."</div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 4, 2014 at 12:08 PM, Jonathan Carter <span dir="ltr"><<a href="mailto:jonathan.carter@owasp.org" target="_blank">jonathan.carter@owasp.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Trusted execution environments are one potential solution to this.  The huge problem we've seen with the TEE approach is that no real widespread adoption because of the hardware aspect.  There's a lot of bureaucracy that has kept everyone from playing in the space.  Hence, things like Android's Kitkat release introducing HCE as a viable alternative that frees you from the hardware implications. <br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 4, 2014 at 12:03 PM, Andre Gironda <span dir="ltr"><<a href="mailto:andreg@gmail.com" target="_blank">andreg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><p dir="ltr"><br>
On Nov 4, 2014 10:53 AM, "Jonathan Carter" <<a href="mailto:jonathan.carter@owasp.org" target="_blank">jonathan.carter@owasp.org</a>> wrote:<br>
><br>
> Things have changed significantly over the past few years within mobile.  There are now a number of new design factors that force organizations to store, transmit, or process things that are extremely sensitive within mobile apps now. In more and more situations, sensitive code must exist within the mobile code. Here are some examples (off the top of my head) where sensitive code must exist on the mobile device: offline availability requirements, HCE, IoT interfaces, mobile banking, medical device interfaces, etc.</p>
</span><p dir="ltr">These can also be implemented using FOSS trusted environments, such as Open-TEE.</p>
<p dir="ltr">My suggestion would be to move the M10 language towards trusted execution environments.</p>
<p dir="ltr">dre<br>
</p>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OWASP-Leaders mailing list<br>
<a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Jason Haddix</div><div>OWASP Mobile Top Ten Project Leader</div><div>Mobile Security Researcher</div><div>(805) 698 2885</div></div></div>
</div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>OWASP-Leaders mailing list</span><br><span><a href="mailto:OWASP-Leaders@lists.owasp.org">OWASP-Leaders@lists.owasp.org</a></span><br><span><a href="https://lists.owasp.org/mailman/listinfo/owasp-leaders">https://lists.owasp.org/mailman/listinfo/owasp-leaders</a></span><br></div></blockquote></body></html>