Fwd: [guardian-dev] SQLCipher adopted by WeChat and their 300M users

[Nathan of Guardian]

-------- Original Message --------
Subject: [guardian-dev] SQLCipher adopted by WeChat and their 300M users
Date: Tue, 10 Dec 2013 03:42:50 -0500
From: Nathan of Guardian <nat...@guardianproject.info>
To: Guardian Dev <guardi...@lists.mayfirst.org>


Through some of our own recent sluething, Citizen Lab's research into
"Asia Chats" security, and now via this third-party post, it has been
recently discovered that WeChat for Android uses SQLCipher for local
data encryption in its app.

http://blog.emaze.net/2013/09/a-look-at-wechat-security.html

Now, as with most things WeChat, the actually implementation is not that
ideal, utilizing a short key, generated in part from the device's ID,
and some sort of server provided token. Still, at least they tried, and
SQLCipher is considered stable enough to run on 300 million devices
around the world.

Who knows, maybe the devs are on this list or the SQLCipher list, and we
can help them improve there implementation using CacheWord!

More from the emaze post below...
*****

WeChat locally stores application data in an encrypted SQLite database
named "EnMicroMsg.db". This database is located in the "MicroMsg"
subfolder inside the application's data directory (typically something
like "/data/data/com.tencent.mm").

The database is encrypted using SQLCipher, an open source extension for
SQLite that provides full database encryption. The encryption password
is derived from the "uin" parameter (see previous sections) combined
with the device identifier through a custom function. More precisely,
the key generation function leverages the mangle() function shown in the
previous Python snippet. The actual database encryption key can be
generated through the following pseudo-code:

password = mangle(deviceid + uin)[:7]

Here deviceid is the value returned by the Android API function
TelephonyManager.getDeviceId(). Follows a sample SQLCipher console
session that demonstrate how the EnMicroMsg.db database can be decrypted.

$ sqlcipher EnMicroMsg.db
sqlite> PRAGMA key = 'b60c8e4';
sqlite> PRAGMA cipher_use_hmac = OFF;
sqlite> .schema
CREATE TABLE conversation (unReadCount INTEGER, status INT, ...
CREATE TABLE bottleconversation (unReadCount INTEGER, status INT, ...
CREATE TABLE tcontact (username text PRIMARY KEY, extupdateseq long, ...
...

It is also worth pointing out that, as the key generation algorithm
truncates the password to 7 hex characters, it would be not so difficult
for motivated attackers who are able to get the encrypted database to
brute force the key, even without knowing the uin or the device identifier.
_______________________________________________
Guardian-dev mailing list

Post: Guardi...@lists.mayfirst.org
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev

To Unsubscribe
Send email to: Guardian-dev...@lists.mayfirst.org
Or visit:
https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianproject.info

You are subscribed as: nat...@guardianproject.info

[William Gray]

Hi Nathan,

Great news! Since I first got wind of this I've been trying to find a clip of Jon Stewart (or John Oliver) on The Daily Show saying, "what the F#&% is WeChat???" It was in a pretty segment about the first PRISM revelations, I believe, and similar to my own reaction when I saw it in the slides along with other networks we hear about more commonly. WeChat is BIG! Great to see the news, maybe we can help them to use a stronger key?

Do you usually recommend using CacheWord over SQLCipher's own key derivation these days?

Cheers,
Billy

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "SQLCipher Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sqlcipher+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.