Here’s some of the work we’ve done:

10/07/2013 – Final project proposal has been proposed and been posted on blogs

10/14/2013 – Get the feedback of final project proposal

10/21/2013 – According to the feedback, we have deeper discussion on final project.
1. Download the source code for CMAccount, and learn about each module of the system
2. Build diagrams to have more clear relationship between each crypto classes
3. Do analysis on the exact crypto and protocols used in CMAccount
4. Come up with MITM and other attacks (thread model), and analyze the whether the security properties in CMAccount can prevent those attacks
5. If time permitted, do more analysis on the correctness of CMAccount

11/02/2013
We have successfully identified the core crypto modules in CMAccount source code. More information can be found on the post: http://cmaccount.blogs.rice.edu/2013/11/03/status-update-11032013/

Future milestones:

11/11/2013
Analyze the specific crypto code, and learn more about ECDH algorithms and algorithms on the digital signatures to sign the public keys before exchanging them (Use a secure medium, such as voice communication or trusted courier, to transmit a digital signature key between the two parties; use a public certification authority (CA) to provide a trusted digital signature key to both parties.).

11/22/2013
Build one or more reasonable threat model, and then analyze the behavior CMAccount will do to deal with them. Then see whether CMAccount is really effective in preventing those sorts of attackers.

11/27/2013
Look over the code again, but this time try to find out whether there’re some potential bugs or mistakes in code.

12/2/2013
Final presentation for projects

We have successfully identified the core crypto modules in CMAccount source code. There are several classes involved:

1. AuthClient
2. GeneratePublicKeysTask, ECDHKeyService
3. EncryptedMessage
4. EncryptionUtils

This app first uses ECDH to generate the key pair between two parties so that they can use AES to encrypt subsequent messages. But, ECDH key exchange protocol does not authenticate the senders of the public key, thus it does not prevent man-in-the-middle attacks. So we are going to analysis more about whether CMAccount has applied any digital signature mechanisms.

In this application, the author has request for an additional token to verify the identification of the sender.

Next steps: Analyze the specific crypto code and see whether CMAccount is free of MITM or some other attacks.

Appendix:
Following graph is the UML diagram for CMAccount source code

1    Introduction

CyanogenMod is an Android distribution aiming to provide more customizable experience to Android users. Recently, they added a new integrated end-to-end encrypted feature called CyanogenMod Account which helps users find their misplaced phone or securely wipe their data in the case of lost phones.

Nowadays, there exist lots of applications on Android market that support these func- tionalities. They usually request permissions to user locations before installation and users never know what these applications actually do with their location information once the permissions are given.

The creators of CyanogenMod Account, however, stated that they would never sell the data or track/wipe the device illegally. Is this true?

2    Objective

In this project, we want to see if CyanogenMod Account obeys their private policies. Specifically, we check the following aspects:

• The actual location is not sent to or stored on their servers;
• Location information is always encrypted before it is sent to the servers;
• The protocol makes sure that the user himself is the only one who can track/wipe his device.

3    Methods

Basically, we want to use two methods – static analysis and dynamic verification.