From noloader at gmail.com  Sun Feb 17 14:27:01 2013
From: noloader at gmail.com (Jeffrey Walton)
Date: Sun, 17 Feb 2013 09:27:01 -0500
Subject: [Owasp-mobile] [SC-L] OWASP Cheat Sheet for iOS App Developers
In-Reply-To: <CAH8yC8mFSV2swC2u9YCqMthN8R0onEtJam5-h_4LV6wyzM-YwQ@mail.gmail.com>
References: <A66B7204-A473-4CD7-842E-ECDAF28F7B4E@krvw.com>
	<CAH8yC8mFSV2swC2u9YCqMthN8R0onEtJam5-h_4LV6wyzM-YwQ@mail.gmail.com>
Message-ID: <CAH8yC8kWLYqZ70sEHUhpOt3FTGxmUnJz3w1PBB2eCLAUogyqpg@mail.gmail.com>

Hi Ken/All,

> iOS Cheat Sheet > Freely available examples include
> iOS Cheat Sheet > SQLcipher (see http://sqlcipher.net).
> Encryption only, and not authenticated encryption :(
It appears this has changed (or has been documented). From
http://sqlcipher.net/design/:

<quote>Every page write includes a Message Authetication Code
(HMAC_SHA1) of the ciphertext and the initialization vector at the end
of the page. The MAC is checked when the page is read back from disk.
If the ciphertext or IV have been tampered with or corrupted the HMAC
check will cause SQLCipher to report a problem with the
database.</quote>

SQLCipher also uses the correct pairing of the primitives. There are
three type of Authenticated Encryption. Two are difficult to get
right. The third is the one we want to see (Encrypt-then-Authenticate,
EtA). Its provably secure when (1) using a stream cipher that XORs the
keystream with plaintext or (2) using a block cipher in CBC mode.

Given a choice between data in SQLCipher or a container in AES/XTS or
AES/CBC mode, it looks like SQLCipher is the better choice.

Jeff

On Wed, Jul 18, 2012 at 10:59 AM, Jeffrey Walton <noloader at gmail.com> wrote:
> On Wed, Jul 18, 2012 at 9:15 AM, Kenneth R. van Wyk <ken at krvw.com> wrote:
>> Title: OWASP Cheat Sheet -- iOS App Developers
>> Author:  Kenneth R. van Wyk
>> Source: OWASP - the Open Web Application Security Project
>> Date Published: 2012-07-17
>>
>> Excerpt:
>>
>> "This document is written for iOS app developers and is intended to provide a set of basic pointers to vital aspects of developing secure apps for Apple?s iOS operating system. It follows the OWASP Mobile Top 10 Risks list."
>>
>> Full article at: https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet
> Thanks Kenneth. Its always good to see information from OWASP.
>
> iOS Cheat Sheet > Apple previously had an API for testing
> iOS Cheat Sheet > devices to see if they are jailbroken, but
> iOS Cheat Sheet > that API was deprecated in 2010
> I believe Zdziarski has recommendations in Hacking and Securing iOS
> Applications (http://www.amazon.com/Hacking-Securing-iOS-Applications-Hijacking/dp/1449318746),
> Chapter 13.
>
> iOS Cheat Sheet > Freely available examples include
> iOS Cheat Sheet > SQLcipher (see http://sqlcipher.net).
> Encryption only, and not authenticated encryption :(
>
> Here's what I have observed: enc_value = Encrypt(10); SQL_Store("Bad
> passwords before wipe", enc_value). The bad guy performs a bit flip
> (without decrypting): enc_value |= 0x10000000, enc_value decrypts to
> an arbitrarily large number.
>
> iOS Cheat Sheet > Exposing sensitive data to eavesdropping
> iOS Cheat Sheet > attacks is a common issue
> There are lots of problems over the wireless link and the public
> internet. Developers and organizations need to PIN THE CERTIFCATE when
> a pre-existing relationship exists between the {user|device} and
> {organization|server}. Confering trust to a 3rd party has led to
> heartache and misery, and [benign?] users are subverting the system
> (http://www.zdnet.com/apple-tries-to-block-ios-in-app-purchase-hack-fails-7000000985/).
>
> Any plans for Android or Windows Phone?
>
> Windows Phone has really raised the bar with Secure Boot from the SoC
> and firmaware (no iDevice/DFU mode trickery), and I expect it to gain
> popularity in the future among enterprises.