Software Encryption in Mobile Devices
Jennifer Nordwall
School of Innovation
Design and Engineering
M¨
alardalens University
Computer Science
Basic Level
February 17, 2013
Abstract
This thesis is based on peoples need to be able to encrypt sensitive data on their mobile devices. The application will allow them to do so effortless, and also ensure them that the security is up to standard. This will be done by using the RSA algorithm that was implemented with consideration for the iPhones weaker hardware, using the GMP and will be written in Objective-C to take advantage of the big market that is AppStore. The main features of this application is a ”vault” where the user can keep sensitive data, protecting it if the phone gets stolen.
This report describes every part of the application, along with the methods used for both the GUI and the cryptography.
Supervisor
MDH: Rikard Lindell Seed Group: Korin Unka
Examiner Damir Isovic
1
Preface
In early 2011 I decided to head down to New Zealand to improve my english skills as well as trying to finish my degree. Around june that same year I came in contact will a small startup on the outskirts of Wellington through a friend of mine. They were producing everything from commercials to websites for a variety of clients. They had just decided to start developing applications for smart phones, but had no current employee with the necessary skills. I was hired as an intern in an attempt to kickstart their development which started with an in-house application that could help them in their everyday lives. Although I was the only one working on the project, I felt that all of them were very engaged and provided me with a lot of support and good feedback. I spent nearly 4 months at their office before the application was ready to be delivered.
I would really like to thank everyone at Seed Group for this amazing op-portunity to work at a small yet successful all New Zealand company!
Also a thank you to my supervisor Rikard Lindell who helped me on the other side of the world.
Contents
1 Preface 2
2 Introduction 5
2.1 Purpose & Contribution . . . 5
2.2 Overview . . . 5
3 Background & Related work 7 3.1 User interface . . . 7 3.1.1 Objective-C . . . 8 3.2 Similar applications . . . 8 3.3 Cryptography . . . 9 3.3.1 RSA . . . 9 3.3.2 GMP . . . 9 3.3.3 Known issues . . . 10 3.3.4 Current usage . . . 11 4 User Interface 12 4.1 Accessibility . . . 12 4.1.1 Navigation controller . . . 12 4.1.2 Tab bar . . . 13 4.1.3 Table view . . . 14 4.2 Security . . . 15 4.2.1 Login . . . 15 4.2.2 Change of password . . . 15 4.3 Interaction . . . 17
4.3.1 Using the information . . . 17
4.4 Design . . . 18
5 Storage 19 5.1 Stored items . . . 19
5.2 Structure . . . 20
6 Security 22 6.1 The RSA algoritm . . . 22
6.2 Structure . . . 23
6.2.1 User . . . 23
6.2.3 RSA . . . 24
6.3 Implementation . . . 24
6.3.1 Creating the key set . . . 24
6.3.2 Login . . . 27
6.3.3 Change of passcode . . . 27
6.3.4 Logout . . . 27
6.3.5 Encrypt . . . 28
6.3.6 Decrypt . . . 28
7 Results & Discussion 29 7.1 Benchmarks . . . 29 7.1.1 Encryption . . . 29 7.1.2 Decryption . . . 30 7.1.3 Key generation . . . 31 7.2 Security issues . . . 32 7.3 User interface . . . 33 8 Future work 36 8.1 File formats . . . 36 8.2 Optimization . . . 36 9 Conclusion 37 10 Acknowledgement 37 11 Appendix 38 11.1 RSA.h . . . 38 11.2 RSA.m . . . 39 12 References 45
2
Introduction
At more than one occasion the thought hit me, ”What would happen to my information if my cellphone got lost or stolen?”. People have a tendency to forget the amount of sensitive data they keep stored on their phones, everything from private photos to passwords to their bank account. With all sorts of different insurances it’s never a question about the money when a phone is getting lost. However, as our gadgets get increasingly advanced, the price and desire to steal them keeps rising. How can we protect those things that no insurance company can cover? Our secrets.
2.1
Purpose & Contribution
The purpose of this work is to create an application which allows the user to store sensitive information and still makes it accessible. It should be more of something that can blend in with our everyday life, rather than being some-thing that we are forced to use. The application needs to be easy to learn and simple to use. This is accomplished by looking at what other people have done in the past and then combining and simplifying the ideas. This will then be tried out on people to make sure that they can find what they are looking for in the smallest amount of time as possible.
This will then be combined with the RSA algorithm that will protect their data. RSA is usually not used in mobile devices due to its large amount of heavy calculations. My work here was to try and look in to different ways to optimize the procedure so that it could run on a mobile device. This was done by combining other peoples work on the matter and measure the effects. The algorithm is then implemented using a library called GMP which helps us with the mathematical operations needed.
2.2
Overview
First of all we will have a look at what has been done before, both when it comes to user interfaces and RSA. Then in section 4, I will describe how this interface was made by keeping all this information in mind. The most important chapters are 5 and 6 where we discuss how the encryption is made and its result stored in the device. The focus here is really how to perform such a heavy algorithm on a limited device in the best way possible. Finally,
we discuss possibly issues and room for improvement in chapter 7, along with some benchmarks showing how fast the encryption/decryption is. In the final 2 chapters we will discuss what the outcome was and how to improve the work that was done.
3
Background & Related work
A lot has happened through out the years, both in the field of cryptogra-phy and software development. For example, the smart phone wasn’t even invented until recently. The touch screen opened up a entirely new way of developing software. Some concepts of how to develop user friendly appli-cations remained the same, but a lot had to be redone. Today, a lot has happened. We have the opportunity to look back at things that already ex-ist, and learn from it.
This section will talk about research that has been made on how to cre-ate an user-friendly interface, but also about applications that already exist that we can learn from. This will make a good foundation when building an application that needs to be simple to use. However, in spite of the fact that the smart phone opened up a world of possibilities, it also made it re-ally hard to run demanding software due to its lack of computing power and storage. Even though the cryptography technique that will be used in this application is well known and has been with us since the 70’s, we have too look at possible issues when using it on a mobile device.
This section will also explain the different techniques that will be used.
3.1
User interface
How humans wish to interact with their mobile devices is a hot topic in to-days society. Due to the massive amount of information we are supposed to keep track of, everything from personal notes to software keys, anything that helps us in our busy lives is always welcomed. We want to be able to store information that is easy to frequently create, access and destroy [9]. Even though many mobile applications enable us to do so to some degree, many people still rely on more conventional methods such as post-it notes.
One of the reasons for this is that people find that the information takes too long to enter or edit. Even though individual fields for information is easier to store and query, the user still needs to have the opportunity to make an unstructured note on the go. The analysis of Natural Language Interface (NLI) also brings up the issue of the small screen and how the user needs to locate the correct application before being able to store their information. A
solution to this would be an NLI portal that would help the user to locate the correct application [8]. The faster the user locates where and how they can enter and edit the information, the more likely is it that they will keep using it. Moreover, by integrating applications that share information, one can increase functionality [14].
An extensive research was performed by Rolf Molich and Jakob Nielsen in 1990 where they presented nine principles that would make an interface more user friendly [11]. Some of the key principles where:
• The dialogues presented to the user should be relevant and simple. • Consistency is key. The user should never have question whether a
button changes its action.
• The user needs to be informed about what is going on. • Provide clearly marked exits and shortcuts.
• The user short-term memory is limited, forcing us to provide the user with information at all times.
3.1.1 Objective-C
Objective-C is an object oriented programming language that was developed by Apple in 1983. It is primarily used in Apple’s current operating system as well as their mobile platform, iOS. It combines the object oriented Smalltalk-style messaging with C (a non object oriented language). Combined with the CocoaTouch API, which includes gesture recognitions and animation, this is currently one of the best options when building mobile applications. One other strong feature this language has is the ability to let you use already existing C libraries, without any further integration.
3.2
Similar applications
After just a quick search, one will find a small group of different applications that are trying to protect either your photos or passwords. Companies often focus on one thing, and as a user the thought of swapping between appli-cations makes it too complicated and time consuming. An application that would, instead of making life harder in exchange for privacy, make the way
we handle sensitive information a lot easier and dynamic.
A few examples of applications for iPhone are the following:
• Private Photo Vault by Enchanted Cloud Studios. The application allows you to only store photos.
• The Vault by W.B.Veldhuis. Allows you to store a variety of docu-ments.
• Keeper by Keeper Security Inc. - Handles passwords and text based data.
Many of these applications had features that were well designed and easy to use, but Seed Group wanted something that was more of an ”all-in-one” solution rather than having to switch between applications.
3.3
Cryptography
3.3.1 RSA
RSA, which stands for Ron Rivest, Adi Shamir and Leonard Adleman, is an algorithm for public-key cryptography that was first published in 1978. It is one of the oldest and most widely used cryptographic algorithms since it is both suited for signing as well as encrypting data. The algorithm uses two large prime numbers and is mainly based on the problem that there is currently no existing efficient algorithm that will factor large numbers fast enough [10].
However, the question whether the encryption is possible to break or not is widely discussed. Since there is no mathematical proof that RSA is se-cure, it’s more a question of time and resources. Although, there’s a wide range of different implementations and variations being developed of the RSA algorithm in the quest to make it more secure. [5] [6]
3.3.2 GMP
GMP refers to the GNU Multiple Precisions Arithmetic Library which is a cross platform library for C. It is extremely powerful since it does not limit the size of the numbers, although the amount of available memory on the
machine might. It also comes with a line of operations such as determining whether a number is prime or not, one of the key steps in the RSA algorithm.
3.3.3 Known issues
Due to the nature of the algorithm, the higher the bit length (key size) the harder it is to crack. However, there is a range of techniques used to crack plain RSA. Since RSA has no random components, the attacker can do a so called plain text attack. This is due to the fact that the public key can be used by anyone, who can then encrypt an arbitrary plaintext and compare it to the cipher-text. This allows the attacker to gain some useful information which can reduce the security of the encryption, and possibly even reveal the secret key. To avoid this issue, the user can use some form of random-ized, structured padding on the plaintext before encrypting it. Depending on what form of padding that is used, the user will gain extra security since the padded text might vary both in length and context from the original plain-text, making it much harder for the attacker to find commonly used phrases in it. This is however not always fail proof and attacks against it do exist [12] [2].
Another issue with the RSA algorithm is how to make it both secure as well as fast to use. During both encryption and decryption we perform modular exponentiation (me (mod n)) (see section 6.1) which can be an expensive
operation in terms of both speed and computing power. It is said that by choosing exponent e so that it has a relative short bit length ( 216+ 1 ) which will result in a small amount of modular squaring, combined with a small Hemming weight (a low number of 1’s in the binary representation of the integer) will potentially result in a faster running encryption [7] [4]. This is especially important when running the algorithm on mobile devices due to their limitations in speed. However, applying to same guidelines on the exponent for decryption is not as easy since d (see section 6.1) is the result of higher number of complex calculations. Also, the bit length of d is directly linked to the key size of the primes, something we cannot decrease for the purpose of speed due to the impact it would have on the security.
A report from 2009 brought up the subject of the amount of computer power it takes to actually generate two large prime numbers that are more than 14 digits long on a mobile device. They came up with the concept of storing
already generated primes in an accessible database which the Sieving prime generation algorithm could use when determining whether the number is a prime or not. They noticed a dramatic increase in terms of speed on large numbers [3].
3.3.4 Current usage
As stated previously, RSA is one of the most widely used cryptographic systems today. The following are a few commonly used tools of today.
• ssh-keygen is a UNIX utility tool that manages authentication keys for ssh authentication[1].
• Telia is currently using RSA 2048-bit encryption for their electronic-identification [13].
4
User Interface
Since we are limited to a very small area of space when working with mobile devices such as the iPhone, efficiency is key. We need a combination of techniques to be able to achieve a fast interface where the user can find what they are looking for without too much effort. This chapter will describe in detail how such a user interface was made so that the user never has to pay too much attention to it. This was done by studying what other people have done, but also simplifying things to make them easier to use.
4.1
Accessibility
4.1.1 Navigation controller
Most of the data will be split into categories depending on their data type, and then yet again into a smaller user defined subcategory that will help the user to organize their data as they desire. This creates a hierarchy of data which demands a technique that can display this to the user in an intuitive way.
Figure 1: One data type and its categories and subcategories.
The UIKit Framework, which comes with the Cocoa Touch API, provides us with the UINavigationController class. The UINavigationController uses a queuing technique known as a stack to reflect the hierarchical structure of the data. It simply starts out with a default view that is the base of the stack. Then, whenever the user goes to the next subcategory, that view is pushed upon the stack. If they then decide to go back, they can do so by popping the view of the stack to return to the previous one by using the navigation bar that is located on the top part of the screen. This bar also
lets the user to know their current view, as well as the name of the previous one, preventing the user from having to remember too much. [11]
Figure 2: The transition between two views.
The UINavigationController class not only provides us with a seamless tran-sition between views, it also lets us fill the navigation bar with easy accessible buttons, leaving us with more space for the actual content. This area will be filled up with image buttons that are easily to figure out since they are consistent with many of the other applications that come with the iPhone. The buttons (add, edit and delete) will also stay in the same order at all time, making them easier to locate [11] .
4.1.2 Tab bar
While the navigation controller handles the views and the transition between them, we still need a way of representing the data. When dealing with a set number of categories, the UITabBar provides an excellent way of represent-ing them usrepresent-ing tabs. The decision was made to have tabs for the different data types since they won’t change in numbers, and it gives a good overview of them and their individual subcategories.
The UITabBar works in combination with the UINavigationController. Ev-ery time one of the tabs is selected, a new view is created and replaces the one that is currently visible (top of the stack). The user will not notice that the current view is popped of the stacked and another similar view is pushed on to it since it happens instantaneously.
4.1.3 Table view
The UITableView class, which is a subclass of the UIScrollView, allows the user to scroll through a list of data which is displayed as a table. The view, however, does not contain any data in itself and is instead based on the MVC architectural pattern (Model-View-Controller) which is an important part of the Cocoa API. The data (Model) becomes separated from the user interface (View) which for example means that we don’t have to redo the interface, just because the data might get changed. A third component, the Controller is put in-between them that controls how the data vill be displayed.
In Objective-C the names differ, but the principle is the same. This mean that whenever you are implementing a UITableView, that object must have a delegate (Controller) and a data source (Model). This is done by reimple-menting functions that specify what data that will be displayed at a specific row in the table view (data source) or what will happen if the user selects one of the rows (delegate).
Figure 4: The data type ”Password” is selected which displays its categories in the table view.
4.2
Security
An application that protects information needs both a login, as well as the ability to change password whenever the user wishes to do so.
4.2.1 Login
The login is the first view on the UINavigationControllers stack and the user must provide a correct password to get to the next step. A UIPickerView is used as a subview of the login window since it is very easy to customize to get the desired design. Also, it allows the user to correct the password before signing in, making it harder to make typing mistakes.
4.2.2 Change of password
When changing password, there are usually 3 mandatory steps that are ex-pected by the user.
1. Authentication: Confirm that the user is the one they claim to be, hence force them to enter their current password. If this step fails, they will be logged out to prevent them from doing further damage.
2. New password: If the user passes step one, it will enter the new password. If the user wishes to change their mind, they should be able to cancel the operation without any password changes.
3. Confirm new password: The user is asked to confirm the new pass-word. If this password doesn’t match the one entered in step 2, the user will start over at step 2. The user can still change its mind if desired.
To be able to create this we need to use another local UINavigationCon-troller as well as a design pattern called the ”delegate pattern”. Firstly, a new UINavigationController will be created when the user decides to change the password, and the view representing step one will become the first item on the stack. This local navigation controller will then be presented and the user will be asked for authentication. Since the navigation controller is located in the class presenting it, we have no control over it in the view we are currently presenting. So, to be able to enter step 2 (new password), we need the ”delegate pattern” which is when the delegate (the settings object where we create the local navigation controller, which will act as a helper), executes tasks for the delegator (the view that is located on the local nav-igation controller which is currently ”step 1”). By creating methods in the delegate class that performs pushing or popping views from the local navi-gation controller, dismissing the presented view (cancel) and popping every single view so that we end up at the start (logout), we allow the delegator to have some control over what’s happening.
To make it a bit more clear, an example is in place. When the user just entered their current password they will automatically continue to the next step. However, before deciding which step that will be, the password will be tried. If it is wrong, the current view will send a message to its delegate (the settings object) asking it to proceed the logout method. The delegate will dismiss the delegator, as well as every single view on the main navigation controller. The user will get logged out and without knowing the password, there will be no way back in. If, however, the user gets the password right, the delegator will send another message to its delegate and tell it to push the ”New password” view on the local navigation controller. From this step the user can cancel the operation, and if deciding to do so the delegator will yet again send a message to the delegate which will simply dismiss the current view. If the user instead wish to proceed with the password change the ”step 3” view will be pushed upon the stack by the delegate and the user may finish the password change if they enter the new password correctly (or the user will have a chance to start over at the ”step 2” view). As you clearly can see, the delegator has full control over what view it wants to be replaced by, but never more control that the delegate gives it. This is a very powerful pattern that is commonly used when passing information between objects.
4.3
Interaction
4.3.1 Using the information
Since most of the confidential information the people at Seed Group wished to store was for either credit cards or logins to sites on the internet that they used everyday, they wanted an easy way to access it. To solve their situation a web browser was put in place which they could access through the details page. The UIWebView is used to embed web content in the application. The
Figure 5: The user entering Facebook through the application along with their credentials.
problem now was how to transfer the information from the detail page to the pages input fields. Filling out the forms automatically wasn’t an option since it might not always be correct, and what if the user decides to use the infor-mation again, but in a different location?
The solution was to use a combination of buttons placed on the navigation bar with javascript. When the user presses the ”Access Website” button (which only will be enabled if the used provided a url with the details) a web view will be displayed that is loading the provided url. Two or more buttons will represent the different strings that are stored, for example ”username”
and ”password”. When selecting one of the form fields and then pushing one of the buttons, that string will be inserted into the field. This is accomplished by first creating the following javascript string:
NSString *jScript = [NSString stringWithFormat:
@"var field = document.activeElement;" "field.value=’%@’;", value];
Where ”value” is for example the user’s stored password and the ”docu-ment.activeElement” is the field that is currently highlighted.
We then call the following method to run our javascript that will insert the password string into the highlighted field:
[self.webView stringByEvaluatingJavaScriptFromString:jScript];
The user can then continue to browse the web inside the local browser and use their information as often as they want.
4.4
Design
To be able to have a great consistent design that is easy to customize with-out too much effort an Interface class was put in place and initialized as a singleton. This means that it will be an object that there can only exist one instance of and it will be allocated when called for the first time. This object will then contain information on what color the navigation bar will have and what size the standard text will have. It makes it very easy to make changes to the design since we only need to change the value at one place.
5
Storage
5.1
Stored items
Due to the amount of additional data that needs to be stored along with the password, document or credit card, a wrapper was put in place. The wrapper holds the following information:
catID The id of the category it belongs to. Can be set to 0 if it doesn’t belong to a category.
siID An id that identifies that specific object and is used as the filename when the file is stored in the filesystem. This is so the filename doesn’t give away any important information about the encrypted file.
dataType What kind of data it is, password, document or credit card.
changed This keeps track of whether the object has been changed or not since it was decrypted from storage. When an object is created this value is always true. This value is later used to determine whether or not an object should be encrypted and saved to the filesystem. If nothing has changed, there’s no need to re-encrypt.
Along with this information a pointer is stored to the object that it’s contain-ing, which could in fact be whatever you like, as long as it has a dataT ype that suits it so that we know how to display and handle it. This structure allows the developer to extend the application with different kinds of data type such as images. All they have to do is add a new dataT ype, define how this data type should be displayed in the GUI and how it gets encrypted/decrypted.
5.2
Structure
The key issue with the storage is how to structure the data. Since we are dealing with categories, we have to consider what the best way of linking the files to their category is.
Strong By having a separate container for every category, we can use it to store the objects that belong to that category. Although this is the easier way of doing it, what if the user wishes to delete a category but not the objects that belong to it?
Soft By keeping the categories and the data in different lists, we need to store extra information in both of the objects. Since we should be able to change the name of a category, we instead have to keep an identification number that won’t change. Then the data object will store the ID of the category it belongs to. This demands a bit more work when displaying objects from a specific category, since we would have to go through the objects and look at what category it belongs to. However, if the user wishes to delete a category, they can easily do so and still keep the stored data (which now of course will be without a category).
The second option was chosen due to the fact that the data will be stored in one single place and not scattered in different containers. For example, if we picked the first option we would have to create folders in the file system with the same name as the category, that would contain the objects. Then, if we want to change the name of a category, we would have to the change name of the folder. We would have to actually move the files to somewhere else if the category was deleted.
Figure 7: A diagram describing how the objects are linked together.
We instead have only three different lists containing the stored item objects, one list for every data type. We also have one list with categories, where every category object contains both the name and a unique ID. These lists are then stored in the Users Database object which also comes with all the necessary methods to query the lists. For example, if the user steps into one of the category views linked to the password view, they expect to see every password of that category. This list of passwords is a temporary sublist and is re-created every time the view loads since its content might not be correct the next time (items might have been added to/deleted from that category since last time).
6
Security
6.1
The RSA algoritm
The following algorithm will create both the public key and the private key.
1. Choose two distinct prime numbers p and q, that don’t differ too much in bit length.
2. Compute the shared modulus for both keys. The bit length of n is referred to as the key size of the algorithm.
n = pq (1)
3. Compute
φ(n) = φ(p)φ(q) = (p − 1)(q − 1) (2)
4. Choose a prime number e so that is more than 1 but less than φ(n). Although it is said that if e has a short bit-length and small Hamming weight it will result in a more efficient encryption, small values such as 5 are not recommended.
5. Determine d as:
d ≡ e−1 (mod φ(n)) (3) By combining n and e we have our public key, and n and d become our pri-vate one.
Encrypt m:
c = me (mod n) (4) Decrypt c:
6.2
Structure
Figure 9: A class diagram describing how the three classes work together when either creating the keys or decrypting/encrypting a file.
6.2.1 User
The User object gets created at the beginning of the application when the user decides to log in. The User object has nothing to do with the creation of the key set or the encryption. However, if there are already existing keys in the filesystem, the User imports them and assigns them to its own individual key set after sending them for testing to the RSA object (in this way we can, if we want, have multiple users that store their own set of keys in different locations). If no keys were found, the User instead requests the RSA object to create a new set. As you can see, the User object only holds its own keys but it has no way of creating or using them. It fully relies on that the RSA object is correct when determining if the key set is valid or not, before granting the user access (more on that later). Also, when the user wants to encrypt or decrypt its data, it needs to include the suitable key pair as an in-parameter of the method call to its Database object.
6.2.2 Storage
When encrypting, the Database object’s job is to first loop though its objects to find the ones that need to be encrypted. It then creates a file handle that determines where the file will be located. Together with the file handle and the object that needs to be encrypted, it also passes on the public key pair given by the User to the RSA object that will take care of the encryption. It
handles decryption in a similar way. The database does not hold on to the key set.
6.2.3 RSA
The RSA object acts fully as a helper class and does not care what key set or objects it is dealing with. This enables us to have more than one user since it never stores any of the keys it creates. The only thing this class keeps track of is the key size that will be used when creating the key sets.
6.3
Implementation
6.3.1 Creating the key set
Since we do not want any restrictions in terms of the bit length when doing this algorithm, the GNU Multiple Precisions Arithmetic Library will be used. If we weren’t using GMP we would only be able to have a very small key size due to the integer overflow the calculations would cause. This would be very restricting and unsafe since it would not require too much time to crack the encryption.
The GMP library not only enables bigger key sizes, it also helps us pick-ing prime numbers. The first step in the algorithm is to create two prime numbers using the following methods.
Here the variables are created and initialized. Notice that they must be freed when we are finished with them just as any other heap allocated objects.
mpz_t max_keysize, p, q;
mpz_init(max_keysize); mpz_init(p);
mpz_init(q);
Since our keySize variable only tells us the bit length, we need to raise two by this number to get our actual max prime. Also notice how the key size is decided by two This is because we usually refer to the modules n when
talking about the key size of the algorithm. And since q and p together creates n, they need to be of half the bit length. 1
mpz_ui_pow_ui(max_primesize, 2, (self.keySize / 2));
A default randomizer is created and both p and q gets assigned with big random numbers that are less than max prime.
gmp_randstate_t rand_state;
gmp_randinit_default(rand_state);
gmp_randseed_ui(rand_state, time(NULL));
mpz_urandomm(p, rand_state, max_prime); mpz_urandomm(q, rand_state, max_prime);
This is where the magic happens. The mpz probab prime p methods deter-mine whether p is a prime or not. First it does some trivial divisions (divide by 10 for example) and then a number of ”Miller-Rabin probabilistic primal-ity” tests. The second parameter decides how many times these tests are made. Then the method returns 0 if it is not a prime, 1 if it probably is a prime and 2 if it is definitely a prime. If the tests are performed a higher number of times, the return value is more accurate and the chance of return-ing 1 decreases. For our purposes a return value higher than 0 is enough, and otherwise a new random value is assigned to p. However, a return value of 1 might mean that the number is only a composite and not a prime, which will jeopardize the security of the algorithm.
while(mpz_probab_prime_p(p, 100) == 0) { mpz_urandomm(p, rand_state, max_prime); }
When finding a prime number for q we also have to make sure that q and p are not the same prime using the comparison method.
while((mpz_probab_prime_p(q, 100) == 0) || (mpz_cmp(p, q) == 0)) { mpz_urandomm(q, rand_state, max_prime);
}
Now when we have both p and q we will calculate n (which is provided as an in-parameter and will not have to be initialized here):
mpz_mul(n, q, p);
Initialize and compute φ(n): mpz_t t_n; mpz_init(t_n); mpz_sub_ui(p, p, 1); mpz_sub_ui(q, q, 1); mpz_mul(t_n, q, p);
e is assigned to a number with a short bit length as well as a small Hemming weight, which increases the efficiency of the algorithm during encryption. This is very important when performing the encryption on a mobile device with less computing power compared to a standard personal computer. e is also an in-parameter and does not have to be initialized.
mpz_set_ut(e, 65537); // 2^16 + 1
The only thing that’s left is to calculate d which is the inverse of e modulo φ(n). Notice that d might not always exist and will then be set to 0.
mpz_invert(d, e, t_n);
Notice that this procedure will not always create a working key set since the last step might return 0. By testing the newly created key set we will be sure that they are correct. Here we pick a number, encrypt and decrypt it and then compare it to the original. If they don’t match up, we need to redo the keys. This is a procedure we rarely have to go through, but it ensures us that our newly generated keys are ready to use!
mpz_t start, result; mpz_init(start); mpz_init(result);
mpz_set_ui(start, 56); // random number
while(mpz_cmp(start, result) != 0) { \\ loop until they match [self generatePossibleKeys_d:d e:e n:n]; \\ create keys \\ encrypt "start" and store in "result"
mpz_powm(result, start, e, n);
mpz_powm(result, result, d, n); \\ decrypt }
6.3.2 Login
The first time the user logs in they will do so with the passcode ”00000”. The default passcode is set when the User object realizes that there are no pre-vious keys in storage and that it has to generate new ones by using the RSA object (as well as delete any stored items that might have been encrypted with some old lost key set). The keys will then have to be stored in the filesystem since they should be replaceable and unique for every application, and cannot be hard coded. The issue soon emerged that it would be too unsafe to keep both the password and the private key in raw text in the file system. A solution to this was to combine the private key with the password before saving them to the file.
part d = d − (user passcode ∗ x) (6)
This means that we do not have to save the password in raw text since it will instead be a part of d. This however forces the user to change their default password, otherwise the d will be stored as it is since 00000 ∗ x = 0 (which will have no affect on d).
So next time when the user decides to log in, the three keys will be im-ported from the filesystem and one of them (d) will be combined with the passcode the user just typed in. The keys will then be tested and if they can encrypt and decrypt something and get the same result as the original (the same test as when the keys are created) the user will be able to login. The correct keys will be stored in the User object so that they can be used when encrypting/decrypting files.
6.3.3 Change of passcode
Since the correct keys are stored in the current User object, these will be used when the user decides to change password. The new passcode combined with x will be subtracted from d and the previous file representing d in the filesystem will be replaced. The user now has to enter the new passcode next time they login.
6.3.4 Logout
When the user gets logged out, the first thing that will happen is that all the items that are changed or added to storage get encrypted and saved to
the filesystem. Then the local storage in memory will be set to nil as well as the user’s passcode (which is saved so that we easily can check against it when changing passcode).
For security reasons, whenever the user returns to the home screen of the device, the application will logout automatically.
6.3.5 Encrypt
First the user calls its storage object, telling it to encrypt the storage and hands it the private key set. The storage then loops through all of the ob-jects, one by one, and if any changes were made to it or if it is new it will be encrypted. The items that are unchanged already exist in the filesystem, encrypted. It then creates a file handle that might replace the old version if there is one, and then ships it of to the RSA singleton object.
The RSA singleton object’s encrypt-method first gets a string from the ob-ject (password, document or credit card) that will contain all the information representing it. That string then gets encrypted, one character at the time. The encrypted strings are stored to a buffer that can hold 20 strings. When the buffer gets full, it gets written to the file. We then continue this procedure until the object string is fully done and go on to the next object.
6.3.6 Decrypt
The decryption is done in a similar way except that we convert one line from the file at a time into a character. That character is added to a string, along with the rest of the decrypted characters. When done, this string gets passed into the constructor of whatever object we are trying to create, which will be able to parse it since it knows how it was created before it was encrypted because it was the one doing it.
7
Results & Discussion
7.1
Benchmarks
7.1.1 Encryption
Four different prime numbers of e were tested, all of which with slightly differ-ent characteristics. Below are the numbers and their binary represdiffer-entation. The tests were performed 10 times, and new keys were generated for every test to ensure us that the result had nothing to do with that specific key set.
Decimal Binary Length
28,657 110 1111 1111 0001 15 65,537 1 0000 0000 0000 0001 17 1,046,527 1111 1111 0111 1111 1111 20 479,001,599 1 1100 1000 1100 1111 1011 1111 1111 29
Figure 10: Amount of time encrypting a 3 digit number in milliseconds.
As discussed previously, it was said that a short bit length as well as a small Hemming weight was proven to increase the speed of the encryption. In this specific test case the second number (216 + 1) was clearly the fastest even
third number which is not that much bigger it terms of bit length. However, whether this is the result of the small Hemming weight is hard to say without more extensive testing. Also, a significant improvement was only recorded on higher key sizes and will not have any impact on the performance on our mobile application since we are not using key sizes higher than 2048 due to performance issues.
7.1.2 Decryption
As expected, the speed did not vary depending on the e. The decryption is a very expensive operation in terms of speed and it would be difficult to apply the same guidelines on d as on e. The reason for that is that d is mainly calculated using the two primes p and q. To be able to find a d with a small Hemming weight would be a very time consuming task since the prime numbers would have to be regenerated until we found a pair that would be suitable. Wether the reward would be worth it or not depends entirely on how much processing power one would have access to during key generation. If this was supposed to be done on a mobile device, the user would have to wait too long for the keys to get created and the it would not be worth it in the end.
7.1.3 Key generation
When generating a pair of keys, they also need to be tested since the algo-rithm might not always return valid keys. We could see some minor benefits when selecting a e with smaller Hemming weight since it would speed up the encryption used in the test. This is however not the most time consuming part of the key generation, but instead the process of finding two district prime numbers. Even though the Rabin-Miller method is significantly faster than methods such as Fermat’s Little Theorem and Eratosthenes’ Sieve on larger number [3], it’s still unacceptable to let the user wait for approxi-mately 3-4 minutes while generating a key set with the key size of 8192. The decision was made that a key size between 1024 and 2048 would be put in use in the application since it would provide the user with both a secure and fast application.
7.2
Security issues
As stated before, the Miller-Rabin method that is used to determine whether a number is a prime or not, is in theory only a so called compositeness test. This means that when the test returns 1, the so called prime might just be a composite or a so called ”pseudo prime”. If the algorithm is no longer based on two real prime numbers, the foundation of which it is based on is no longer valid hence leaving it less secure. However, the chance of it being incorrect decreases dramatically as the number of tests performed increases. The chance of it reporting a composite as prime is:
1
4k (7)
In our case, where k = 100 the case is as low as:
1
4100 = 6.223015 ∗ 10 −61
(8)
Also, due to the nature of the test, there will be no numbers like the Carmichael numbers which will act as prime, no matter how many tests we do. All this concludes to that even though our Miller-Rabin method might not be 100% accurate, the chances of it not being accurate are that slim that they won’t be of any major significance in terms of security regarding our key genera-tion [3]. In fact, we could even lower the number of tests and still have a very good accuracy.
7.3
User interface
The foundation of the user interface was based on many of the guidelines that were developed by Rolf Molich and Jakob Nielsen in 1990 through extensive research [11]. It proved to be a very good base that was then tested by some of the staff at SeedGroup. Some of the questions they had to answer were:
• Did you find the buttons easy to understand? • How easy was it to save a document?
• Was the browser easy to find?
• How did you find the login procedure and changing of password? Originally, most of the buttons where located on a separate toolbar at the bottom of the screen so that more room was left for the text on the top bar. They found this very confusing and thought that an additional bar would leave less space for the actual content. The decision was made to place all of the buttons at the top instead.
They thought that the documents were easy to add and they liked the fact that you could add items to the ”All” category if they didn’t feel the need to categorize them. The browser came as a wonderful surprise since they actually just made a vague request to be able to use their data. One of the staff at Seed Group thought that it was a brilliant idea to only have to type his password once and then have it available at any time. He always had an issue with entering passwords on websites because of the small keyboard which force you to switch mode to be able to write numbers. Before, he found himself using simpler, less secure passwords, so that he could access sites faster. He also didn’t feel that he wanted to save such important infor-mation in his browser in case someone stole his phone. This, he said, was a secure and fast solution, even though the browser wasn’t developed enough.
They thought that the login was quick and simple, but they didn’t feel that they could wait much longer for the decryption to happen. They also requested the feature where you get logged out when pressing the ”home button” since they usually forgot that applications were running in the back-ground on the new iPhone.
The following picture shows the amount of steps the user must take to create a new password object in the ”All” category. All buttons are located on the top bar, just as they requested. The bottom bar was completely removed except for where it act as the tab-bar on the main view. They also requested to be able to see how many items there were in a category, which is the number to the right of the categories in the second picture from the left.
Here the user enters their details and saves it. Only one of the two fields are required and if they add a description it will show up in the item list. When entering the detail page they can do so by selecting one of the fields, just as they would do on many other applications such as Apple’s Address Book. If they instead wish to delete it, they can do so by either pressing the delete button or stroking the item in the item-list which will bring up another delete button. The second option is one of the UITableViews built in data-source methods and is also commonly used in other iPhone applications.
8
Future work
There is still some work left to be done on the application. A better, more stable web browser should be put i place, enabling the user to rely fully on it if they wish to do so. They user should also be able to change the color theme, the length of the password and the key size.
8.1
File formats
Since the code structure is built in such a way that additional data types could easily be added, pictures should be added. The ability to import and view them is already implemented, but was never put in place due to the amount of decryption that would be required. The algorithm would need a lot of improvement for the application to be able to import a larger number of encrypted files from memory. Saying that, there are also a lot of restrictions decrypting a large number of big files on a mobile device such as the iPhone since it has nowhere near the computing power of a desktop computer.
8.2
Optimization
As stated above, the decryption process would have to be optimized for it to be possible to handle a large amount of data. One way of doing this would be to split it into two smaller modular exponentiations using the Chinese Remainder Theorem. The CRT RSA is only one of many improvements of the original RSA that are proven to increase the performance of the decryption. Depending on the scenario, techniques such as Prime” and ”Multi-Power” can perform even faster than CRT RSA. [7]
9
Conclusion
A lot of effort was put on making a GUI that was very simple to use. This was done by a combination of already existing research on the subject and closely working with the customer. When it came to the RSA-algorithm it had to be optimized for a faster running key generation and encryption. To be able to pick a key size for the algorithm we had to perform benchmarking to determine how much time it would take and what would be reasonable. A key size between 1024 and 2048 was chosen, depending on the degree of security that was desired by the customer. Higher key sizes than that was almost impossible to run on the iPhone.
I strongly believe that this is something we will see more of as the mobile devices becomes more developed. Also, I would wish for the US government to have less restrictions on their cryptography policies, making it easier for software developers to develop their own variations of RSA for commercial use.2
10
Acknowledgement
This was a far greater task than I originally imagined. I overestimated the ability of the iPhone as well as underestimated the complexity and time consumption of RSA. This led to that many of my ideas such as image support and instant messaging had to take a step back. However, I soon realized that this was a widely discussed issue which could explain the slim selection of similar applications. I would like to thank the people at Seed Group who were able to lower their expectations and still be very pleased with other features such as the web browser, something they probably will use more than the ability to store images.
11
Appendix
11.1
RSA.h
#include <gmp.h> #include <stdio.h> #include "StoredItem.h"
@interface RSA : NSObject { @private
NSInteger _keySize_index;
NSMutableArray *_possibleKeySizes; mpz_t convert;
}
@property NSInteger keySize;
@property (nonatomic, assign) NSInteger keySize_index;
@property (nonatomic, retain) NSMutableArray *possibleKeySizes;
+(RSA*)main; -(NSInteger)keySize; -(void)setKeySize:(NSInteger)keysize; -(void)encryptStoredItemToFile:(StoredItem*)storedItem fileHandle:(NSFileHandle*)handle n:(mpz_t)n e:(mpz_t)e; -(NSString*)decryptString:(NSString*)handle n:(mpz_t)n d:(mpz_t)d; -(Boolean)testKeys_d:(mpz_t)d e:(mpz_t)e n:(mpz_t)n; -(void)generateKeys_d:(mpz_t)d e:(mpz_t)e n:(mpz_t)n; -(void)generatePossibleKeys_d:(mpz_t)d e:(mpz_t)e n:(mpz_t)n; @end
11.2
RSA.m
#import "RSA.h"
@implementation RSA
@synthesize keySize_index = _keySize_index, possibleKeySizes = _possibleKeySizes;
static RSA *_main = nil;
#pragma mark
-#pragma mark Initialization
+(RSA*)main {
@synchronized([RSA class]) {
if(!_main) [[self alloc] init]; return _main; } return nil; } +(id)alloc { @synchronized([RSA class]) { NSAssert(_main == nil,
@"Attempted to allocate a second instance of a singleton."); _main = [super alloc];
return _main; }
return nil; }
-(id)init {
self = [super init];
if(self != nil) {
self.possibleKeySizes = [[[NSMutableArray alloc]
initWithObjects:@"512", @"1024", @"2048", nil] autorelease]; }
return self; }
-(NSInteger)keySize { return ((NSInteger)
[[self.possibleKeySizes objectAtIndex:self.keySize_index] doubleValue]); }
-(void)setKeySize:(NSInteger)keysize { // self.keySize_index = keysize; printf("setting keysize wont work"); }
-(Boolean)testKeys_d:(mpz_t)d e:(mpz_t)e n:(mpz_t)n { mpz_t start; mpz_init(start);
mpz_t result; mpz_init(result);
mpz_set_ui(start, 56); // 56 == random number
/* encrypt ***/
mpz_powm(result, start, e, n); /* decrypt ***/
mpz_powm(result, result, d, n);
/* make sure it’s the same as the start ***/
if(mpz_cmp(result, start) == 0) { return true;
} else return false; }
-(void)encryptStoredItemToFile:(StoredItem*)storedItem fileHandle:(NSFileHandle*)handle n:(mpz_t)n e:(mpz_t)e {
NSString *stringToEncrypt = [storedItem toString]; NSString *buffer = [NSString stringWithString:@""]; mpz_init(convert);
for(int i = 0; i < [stringToEncrypt length]; i++) {
mpz_set_ui(convert, (int)[[storedItem toString] characterAtIndex:i]); mpz_powm(convert, convert, e, n);
if((i + 1) != [stringToEncrypt length]) {
buffer = [NSString stringWithFormat:@"%@%@\n", buffer,
[NSString stringWithUTF8String:mpz_get_str(NULL, 10, convert)]]; } else { // last line cannot have a new line
buffer = [NSString stringWithFormat:@"%@%@", buffer,
[NSString stringWithUTF8String:mpz_get_str(NULL, 10, convert)]]; }
if(((i % 20) == 19) || ((i + 1) == [stringToEncrypt length])) { [handle seekToEndOfFile];
[handle writeData:[buffer dataUsingEncoding:NSUTF8StringEncoding]]; buffer = @""; } } mpz_clear(convert); } -(NSString*)decryptString:(NSString*)file n:(mpz_t)n d:(mpz_t)d { NSArray *substrings = [file componentsSeparatedByString:@"\n"]; NSString *target = @"";
mpz_t line_convert; mpz_init(line_convert);
const char* line = [[substrings objectAtIndex:i] UTF8String]; mpz_set_str(line_convert, line, 10);
mpz_powm(line_convert, line_convert, d, n); char current = (char)mpz_get_ui(line_convert);
target = [NSString stringWithFormat:@"%@%c", target, current]; }
NSLog(@"%d", [target retainCount]);
//mpz_clear(line_convert); return target; } -(void)generateKeys_d:(mpz_t)d e:(mpz_t)e n:(mpz_t)n { mpz_t start, result; mpz_init(start); mpz_init(result);
mpz_set_ui(start, 56); // 56 == random number
/* CONTROL ***/
while(mpz_cmp(start, result) != 0) {
[self generatePossibleKeys_d:d e:e n:n]; /* encrypt ***/
mpz_powm(result, start, e, n); /* decrypt ***/
mpz_powm(result, result, d, n);
/* make sure it’s the same as the start ***/ }
mpz_clear(start); mpz_clear(result); }
-(void)generatePossibleKeys_d:(mpz_t)d e:(mpz_t)e n:(mpz_t)n { NSDate *start_time = [NSDate date];
mpz_t max_primesize, prime1, prime2, t_n;
//*** Init ***//
mpz_init(max_primesize); mpz_init(prime1);
mpz_init(prime2); mpz_init(t_n);
//*** Compute two prims (maybe) ***//
mpz_ui_pow_ui(max_primesize, 2, (self.keySize / 2));
gmp_randstate_t rand_state;
gmp_randinit_default(rand_state);
gmp_randseed_ui(rand_state, time(NULL));
mpz_urandomm(prime1, rand_state, max_primesize); mpz_urandomm(prime2, rand_state, max_primesize);
while(mpz_probab_prime_p(prime1, 100) == 0) { // 0 = no prime, 1 = prob. , 2 = def. mpz_urandomm(prime1, rand_state, max_primesize);
}
while((mpz_probab_prime_p(prime2, 100) == 0) || (mpz_cmp(prime1, prime2) == 0)) { mpz_urandomm(prime2, rand_state, max_primesize);
}
//*** Compute n ***//
mpz_mul(n, prime1, prime2);
//*** Compute the totient(n) = (prime1 - 1) * (prime2 - 1) ***// mpz_sub_ui(prime1, prime1, 1);
mpz_sub_ui(prime2, prime2, 1); mpz_mul(t_n, prime1, prime2);
//*** e = 2^16 + 1 ***// mpz_set_ui(e, 65537);
//*** Compute d: d^-1 = e mod(t(n)) ***//
// compute the invers of e % tn. NOTE! d could == 0. // somethimes d dosent exist.
mpz_invert(d, e, t_n);
mpz_clear(max_primesize); mpz_clear(prime1);
mpz_clear(prime2); mpz_clear(t_n);
double timeInterval = [start_time timeIntervalSinceNow] * -1000.0; printf("\ngenerate %f", timeInterval);
}
12
References
[1] Ssh kaygen.
Key: Keygen
[2] Daniel Bleichenbacher. Chosen cipherfexf attacks against protocols based on the rsa encryption standard pkcs#. Advances in cryptology, pages 1 – 12, 1998.
Key: Dani98
[3] C. Morris-Wright A Rowlison C. Cavalli, C. McDonald and B. Swenson. The implementation and optimization of the rsa encryption method. 2009.
Key: Canv09
[4] Jeffrey Hoffstein and Joseph H. Silverman. Random small hamming weight products with applications to cryptography. Discrete Applied Mathematics, 130:37 – 49, 2003.
Key: Hoff00
[5] Marc Joye. How (not) to design strong-rsa signatures. Special Issue: Coding and Cryptography, 59(1-3):169–182, 2011.
Key: Marc11
[6] Sung-Kyoung Kim, Tae Hyun Kim, Dong-Guk Han, and Seokhie Hong. An efficient crt-rsa algorithm secure against power and fault attacks. Journal of Systems and Software, 84(10):1660 – 1669, 2011.
Key: Kim11
[7] Hansen Klaus, Larsen Troels, and Olsen Kim. On the efficiency of fast rsa variants in modern mobile phones. 2010.
Key: Hans10
[8] Zhou L. Natural language interface for information management on mobile devices. Behaviour and Information Technology, 26(3):197–207, 2007.
Key: Zhou07
[9] Wayne G. Lutters. Identifying expertise markers in routine work arti-facts: exploring micronote taking behavior. Computers in Human Be-havior, 20(2):185 – 199, 2004.
Key: Lutt04
[10] Punita Meelu and Sitender Malik. Rsa and its correctness through mod-ular arithmetic. AIP Conference Proceedings, 1324(1):463 – 466, 2010.
Key: Meel10
[11] Rolf Molich and Jakob Nielsen. Improving a human-computer dialogue. Commun. ACM, 33(3):338–348, 1990.
Key: Moli90
[12] David Naccache. Padding attacks on rsa. Information Security Technical Report, 4(4):28 – 33, 1999.
Key: Nacc99
[13] Telia. Telias utf¨ardardeklaration, cps, f¨or telia e-legitimation (version b). Technical report.
Key: Telia
[14] Lina Zhou, Ammar S. Mohammed, and Dongsong Zhang. Mobile per-sonal information management agent: Supporting natural language in-terface and application integration. Information Processing and Man-agement, 48(1):23 – 31, 2012.
