• No results found

3.2 The Evaluation Framework

4.1.1 Encryption

Documentation

Both iOS and Android receive full marks on their coverage for encryption as all of the necessary document types for both platforms are provided.

Table 4.1: iOS and Android Encryption Coverage

iOS Android

Secure Data Storage home page X X

Encryption home page X X

Encryption Solution X X

Library docs X X

Recall that documents for iOS and Android may be admitted into the document set as long as they are in their respective platforms primary or secondary database. Because of this, the coverage evaluation yielded interesting results for encryption. Compared to all other coverage evaluations, the encryption coverage evaluation found

the highest number of documents, for both iOS and Android, originating from their respective secondary database. This is interesting because it shows that neither plat- form has made much of an effort to build upon their original encryption documenta- tion. All iOS documents with the exception of the library entries are from its legacy database. And Android is just one off from iOS, having both its encryption landing page and solution residing in Javadocs. For reference, no other coverage evaluation in this paper had more than one document from their set residing in the respective platforms secondary database.

Figure 4.1: iOS Encryption Documentation Structure

Figure 4.2: Android Encryption Documentation Structure

The layout of the iOS encryption document set was well connected with the excep- tion of the solution. The solution turned out to be a stand-alone Objective-C project called CryptoCompatability[29]. It was mentioned as a useful existing project on the encryption homepage, however no functioning link accompanied the mention. As a result it was only found through a Google search. Despite its isolation the project

was quite useful. CryptoCompatability[29] was intended to teach developers about the low-level C cryptography library commonCrypto. As a result, it not only ran examples for symmetric and asymmetric encryption, but also for MACs and numer- ous other cryptographic operations. It even supplied the developer with test data to verify correct implementation of cryptographic mechanisms.

Since the iOS solution was more than one link away from the remainder of the document set, the security mechanism would typically receive a score of zero on its structure. But this evaluation turned out to be a special case. The solution title was mentioned in the security mechanism homepage as a very useful project for learning about iOS encryption. It just wasnt linked. As a result the iOS encryption structure evaluation will receive one out of two points.

Interestingly for Android, they have left pretty much all of their useful cryptog- raphy documentation to be found in Javadocs, their secondary database. As a result, there is a very clear split between their introductory document set pages and their encryption specific documents. The most convenient way to find their cryptography documentation is by going through the library documentation subset. As a result of this split, Android will receive half points for its structure score.

The iOS solution is found as a standalone Xcode project. The project is written up-to-date objective-C code, and is secure. The instructions associated with the solution are simply comments within the project. As a result, the iOS encryption solution will receive a full score on its solution. However, it is worth noting that since the directions are commented into the code, the code is slightly less readable. The solution would likely be a lot easier to follow if there were a separate document with instructions and code snippets to accompany the project.

The Android encryption solution is conveniently on the same page as the Android encryption home page. This page is titled the Java Cryptography Architecture (JCA)

and contains information regarding all cryptographic libraries supported by Java. Android simply adopted Javas cryptography API for all of its cryptographic use cases. At the top of this page is a table of contents that makes it simple to jump directly to the content that you desire. For example, encryption is clearly linked at the top of it. The only issue with this layout is how it provides code solutions. Because the page is so large, the encryption solution and its instructions are fragmented. Although the solution is still secure, up to data and well annotated; it feels as though it is too spread out. Since this issue is similar to the requirement that states the solution must be presented on one page, the Android encryption solution is docked one point. As a result, it receives a score of two out of three on its solution.

Encryption Implementation

As stated in the documentation evaluation, cryptographic documentation for both iOS and Android have been somewhat neglected. This is because neither platform has spent much time building upon their original implementations. Apple requires the developer to work with a low-level C library called commonCrypto[30] to handle a majority of cryptography needs. And Android still requires their developers to work with the original Java Cryptography Architecture (JCA) [31] that they first adopted in their original creation of the platform.

The first step in both asymmetric and symmetric encryption for Android is get- ting an instance of the KeyGenerator[32] and the Cipher[14] for the specific type of encryption. Both steps require using the respective classs content provider. To get an instance of a given class from their content provider the developer must use the respec- tive classs .getInstance() method. When retrieving an instance for the KeyGenerator, one must be careful to pass the correct algorithm. Likewise, the getInstance request for the cipher requires a parameter that is referred to as the transformation. The transformation takes on the form algorithm/mode/padding. As long as the algorithm

being passed to the key generator and the cipher content providers are compatible, the encryption code below will work.

Listing 4.1: Symmetric Encryption (Android - Java)

1 K e y G e n e r a t o r k e y G e n e r a t o r = K e y G e n e r a t o r . g e t I n s t a n c e ( " AES " ) ; 2 S e c r e t K e y s e c r e t K e y = k e y G e n e r a t o r . g e n e r a t e K e y () ; 3 C i p h e r c i p h e r = C i p h e r . g e t I n s t a n c e ( " AES / GCM / N o P a d d i n g " ) ; 4 c i p h e r . i n i t ( C i p h e r . E N C R Y P T _ M O D E , s e c r e t K e y ) ; 5 G C M P a r a m e t e r S p e c g c m P a r a m e t e r S p e c = new G C M P a r a m e t e r S p e c (0 , c i p h e r . g e t I V () ) ; 6 b y t e [] d a t a T o E n c r y p t = ... 7 b y t e [] e n c r y p t e d D a t a = c i p h e r . d o F i n a l ( d a t a T o E n c r y p t ) ;

Listing 4.2: Asymmetric Encryption (Android - Java)

1 K e y P a i r G e n e r a t o r k e y G e n e r a t o r = K e y P a i r G e n e r a t o r . g e t I n s t a n c e ( " RSA " ) ; 2 K e y P a i r k e y P a i r = k e y G e n e r a t o r . g e n e r a t e K e y P a i r () ; 3 C i p h e r c i p h e r = C i p h e r . g e t I n s t a n c e ( " RSA / N O N E / O A E P P a d d i n g " ) ; 4 c i p h e r . i n i t ( C i p h e r . E N C R Y P T _ M O D E , k e y P a i r . g e t P r i v a t e () ) ; 5 b y t e [] d a t a T o E n c r y p t = ... 6 b y t e [] e n c r y p t e d D a t a = c i p h e r . d o F i n a l ( d a t a T o E n c r y p t ) ;

Once an instance of the cipher and the key are created all one must do is initialize the cipher with the specified key, and its mode: init(int opmode, Key key). Then using the doFinal method the cipher will encrypt the input data returning the encrypted data. Also notice that decrypting is quite simple too. The exact same process is used for decryption except the developer must change the opmode in the cipher initialization to DECRYPT MODE.

As identified, there are many configurations that must be decided upon when encrypting data. And as OWASP identifies[33], there are a number of configurations that are inherently bad implementations of encryption. Some common errors include

picking an insecure algorithm, picking a key length that is too small or even using a non cryptographically secure PRNG for the key. Because of the numerous possibilities that can arise in encryption implementation, abstraction of the respective API is likely the most important factor in assessing an encryption APIs usability.

Because there are so many parameters that an encryption API could leave up to the developer an ideal implementation in the scope of this paper would be one that requires no input from the developer. The encryption API call would be secure by default. However, Android chose not to do this, likely because they wanted to leave space for flexible implementation for the many experienced programmer that use the API. Instead Android chose to create a thin layer of abstraction that only requires the developer to specify the algorithm, mode of operation and padding. Upon further investigation this degree of abstraction actually makes a lot of sense. It still allows experienced programmers to implement flexible encryption designs. But at the same time, considers less experienced programmers, and only reveals the need for decision on three of the more common characteristic of encryption. Still though, Android receives a half score on its abstraction. The Android encryption implementation for symmetric and asymmetric encryption is quite simple to incorporate into an existing project. As a result, it will receive full marks on minimality.

Although a number of the parameters for Android encryption are abstracted, the API still requires the developer to know about a number of complex characteristics of encryption. The Android developer must specify the algorithm, mode and padding for the cipher, as well as the algorithm for the key. Despite the fact that Android Studio will warn the developer in certain cases: like when ECB mode is used, typically it will not. As a result, any error in parameter specification will render the entire encryption security mechanism useless. Such an issue is likely since Android still supports a number of insecure encryption algorithms[34]. Therefore Android receives zero points for Encryption implementation robustness.

In contrast to Android, and somewhat frustratingly, the iOS implementation for encryption varies across symmetric and asymmetric encryption. Symmetric encryp- tion is implemented through the commonCrypto[30] API; a low-level C library. And asymmetric encryption is implemented through the Certificates, Keys, and Trust ser- vices API.

Listing 4.3: Symmetric Encryption (iOS - Objective-C)

1 u i n t 8 _ t * s y m m e t r i c K e y = N U L L ; 2 N S D a t a * s y m m e t r i c K e y R e f = N U L L ; 3 s y m m e t r i c K e y = m a l l o c ( k C C K e y S i z e A E S 1 2 8 * s i z e o f ( u i n t 8 _ t ) ) ; 4 m e m s e t (( v o i d *) s y m m e t r i c K e y , 0 x0 , k C C K e y S i z e A E S 1 2 8 ) ; 5 int r e s u l t = S e c R a n d o m C o p y B y t e s ( k S e c R a n d o m D e f a u l t , k C C K e y S i z e A E S 1 2 8 , s y m m e t r i c K e y ) ; 6 s y m m e t r i c K e y R e f = [[ N S D a t a a l l o c ] i n i t W i t h B y t e s :( c o n s t v o i d *) s y m m e t r i c K e y l e n g t h : k C C K e y S i z e A E S 1 2 8 ]; 7 u i n t 8 _ t i v _ t m p [ k C C B l o c k S i z e A E S 1 2 8 ]; 8 m e m s e t (( v o i d *) iv_tmp , 0 x0 , ( s i z e _ t ) s i z e o f ( i v _ t m p ) ) ; 9 r e s u l t = S e c R a n d o m C o p y B y t e s ( k S e c R a n d o m D e f a u l t , k C C B l o c k S i z e A E S 1 2 8 , i v _ t m p ) ; 10 N S D a t a * iv = [ N S D a t a d a t a W i t h B y t e s :( c o n s t v o i d *) i v _ t m p l e n g t h : k C C B l o c k S i z e A E S 1 2 8 ]; 11 s i z e _ t o u t L e n g t h ; 12 N S D a t a * d a t a T o E n c r y p t = ... 13 N S M u t a b l e D a t a * c i p h e r D a t a = [ N S M u t a b l e D a t a d a t a W i t h L e n g t h : d a t a T o E n c r y p t . l e n g t h + k C C B l o c k S i z e A E S 1 2 8 ]; 14 C C C r y p t o r S t a t u s r e s u l t = C C C r y p t ( 15 k C C E n c r y p t , // o p e r a t i o n 16 k C C A l g o r i t h m A E S 1 2 8 , // a l g o r i t h m 17 k C C O p t i o n P K C S 7 P a d d i n g , // o p t i o n s 18 s y m m e t r i c K e y R e f . bytes , // key 19 s y m m e t r i c K e y R e f . length , // k e y l e n g t h 20 iv . bytes , // iv

21 d a t a T o E n c r y p t . bytes , // d a t a I n

22 d a t a T o E n c r y p t . length , // d a t a I n L e n g t h , 23 c i p h e r D a t a . m u t a b l e B y t e s , // d a t a O u t

24 c i p h e r D a t a . length , // d a t a O u t A v a i l a b l e

25 & o u t L e n g t h ) ; // d a t a O u t M o v e d

Listing 4.4: Asymmetric Encryption (iOS - Objective-C)

1 N S M u t a b l e D i c t i o n a r y * k e y P a i r A t t r i b u t e s = [[ N S M u t a b l e D i c t i o n a r y a l l o c ] i n i t ]; 2 [ k e y P a i r A t t r s e t O b j e c t :( _ _ b r i d g e id ) k S e c A t t r K e y T y p e R S A f o r K e y :( _ _ b r i d g e id ) k S e c A t t r K e y T y p e ]; 3 [ k e y P a i r A t t r s e t O b j e c t :[ N S N u m b e r n u m b e r W i t h I n t : 2 0 4 8 ] f o r K e y :( _ _ b r i d g e id ) k S e c A t t r K e y S i z e I n B i t s ]; 4 S e c K e y R e f p u b l i c K e y = N U L L ; 5 S e c K e y R e f p r i v a t e K e y = N U L L ; 6 O S S t a t u s s t a t u s = S e c K e y G e n e r a t e P a i r (( _ _ b r i d g e C F D i c t i o n a r y R e f ) k e y P a i r A t t r , & p u b l i c K e y , & p r i v a t e K e y ) ; 7 s i z e _ t c i p h e r D a t a S i z e ; 8 u i n t 8 _ t * c i p h e r D a t a ; 9 c o n s t u i n t 8 _ t d a t a T o E n c r y p t [] = ... 10 s i z e _ t d a t a L e n g t h = s i z e o f ( d a t a T o E n c r y p t ) / s i z e o f ( d a t a T o E n c r y p t [ 0 ] ) ; 11 e n c r y p t e d D a t a S i z e = S e c K e y G e t B l o c k S i z e ( p u b l i c K e y ) ; 12 e n c r y p t e d D a t a = m a l l o c ( c i p h e r B u f f e r S i z e ) ; 13 O S S t a t u s s t a t u s = S e c K e y E n c r y p t ( 14 p u b l i c K e y , // key 15 k S e c P a d d i n g O A E P , // p a d d i n g 16 d a t a T o E n c r y p t , // d a t a I n 17 ( s i z e _ t ) d a t a L e n g t h ,// d a t a I n L e n g t h

Related documents