Cryptographic Key Masking During Run-Time

Full text

(1)LiU-ITN-TEK-A--08/020--SE. Cryptographic Key Masking During Run-Time Marcus Andersson 2008-02-27. Department of Science and Technology Linköping University SE-601 74 Norrköping, Sweden. Institutionen för teknik och naturvetenskap Linköpings Universitet 601 74 Norrköping.

(2) LiU-ITN-TEK-A--08/020--SE. Cryptographic Key Masking During Run-Time Examensarbete utfört i elektronikdesign vid Tekniska Högskolan vid Linköpings unversitet. Marcus Andersson Handledare Anders Nilson Examinator Qin-Zhong Ye Norrköping 2008-02-27.

(3) Upphovsrätt Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/ Copyright The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/. © Marcus Andersson.

(4) Abstract Many of the products commercially available today contain some form of encrypted or hashed data. It can involve DRM protection, licenses and certificates, signatures or identification information. Regardless of what the data is intended for, it is protected for a reason and may be worth a great deal of money to the owner. There are numerous examples of products that have been subject to hacking in the form of simple memory attacks. If the keys are made all too easily extracted, the value of the protected data will soon be lost. The aim of the thesis work discussed in this report was to evaluate the vulnerabilities in mobile phones to this sort of attacks and to find possible security enhancements that can be applied. A method is proposed where masking will secure the cryptology keys while they reside in the memory. Different masks are developed and tested - The effects on performance are measured and the security is evaluated. The thesis work concludes that it is possible to implement masking on many of the security functions using keys and that the masks will increase security. The conclusion also states that the time consumption of the masking heavily depends on which mask that is used and that the masking could be applied in such a way that the level of masking can be varied.. 1.

(5) Acknowledgements I would like to thank the DRM/Security department at Sony Ericsson, for giving me the opportunity to do my thesis work at their office. Much of the knowledge gathered for this work came from discussions with the people of this department. Special thanks to Anders Nilson, my supervisor at SEMC. Without his guidance, the outcome of this work would not have been the same.. Marcus Andersson February 4, 2008. 2.

(6) Contents 1 Introduction 1.1 Task Definition . . 1.2 Expectations . . . 1.3 Method . . . . . . 1.4 Limitations . . . . 1.5 Thesis Disposition 1.6 Background . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 5 6 6 6 7 7 7. 2 Background Information 2.1 Digital Rights Management (DRM) . . . . . . . 2.1.1 Open Mobile Alliance (OMA) . . . . . . 2.1.2 DRM . . . . . . . . . . . . . . . . . . . 2.2 Certificates . . . . . . . . . . . . . . . . . . . . 2.2.1 Message Authentication Codes (MACs) 2.2.2 Signatures . . . . . . . . . . . . . . . . . 2.2.3 Certificates . . . . . . . . . . . . . . . . 2.2.4 Cryptographic Keys . . . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 9 9 9 10 11 11 11 12 12. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 3 Main Threat. 13. 4 Test Suit 4.1 Memory Iterative Search in Dump-File (MemorySearch) 4.2 Allocation Search in Dump-File (AllocInfo) . . . . . . . 4.3 Run-Time Eavesdropping (FreeAllocLog) . . . . . . . . 4.4 Run-Time Parameter Saving (ParamLog) . . . . . . . . 4.5 Heap Comparison Test . . . . . . . . . . . . . . . . . . . 4.6 Stack Usage (StackLog) . . . . . . . . . . . . . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 14 14 14 15 15 15 15. 5 Filters. 16. 6 Current Situation 6.1 Memory-Dump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Log Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Introduction to Key Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 21 21 21 23. 7 Theory 7.1 The Masking Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Mask Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Previous Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 25 25 27 27. 3.

(7) 8 Implementation 8.1 The AES Encryption Algorithm . . . 8.2 The AES Decryption Algorithm . . . 8.3 The HMAC-SHA-1 Algorithm . . . . 8.4 General Implementation of Masking 8.5 Masks . . . . . . . . . . . . . . . . .. . . . . .. 29 30 30 30 32 32. 9 Results 9.1 AES Decryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 AES Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 HMAC-SHA1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 34 35 36 37. 10 Conclusions. 41. 11 Future Improvements. 43. A Calculation of Sobs Filter Parameter. 48. B Calculation of Run Length Filter Parameter. 50. C Calculation of Runs Limit Filter Parameter. 52. D RSA Keys Let Through Filters. 53. E Allocations Let Through Filters. 58. . . . . .. . . . . .. 4. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . ..

(8) Chapter 1. Introduction Securing information with the use of cryptology is not a new invention. More or less all introductory literature concerning cryptology use the roman emperor Caesar and his very basic substitution cipher as an example. The idea behind cryptology can most certainly be traced back even further, but it is in recent years that it has become widely used. Since the end of the Second World War, the main contributor to the cryptology science have slowly shifted from the military sector into the financial. Even though the military still uses cryptology and most likely always will, cryptology has found new ground on Internet and in most of our electronics equipment. Sony Ericsson is a joint venture between the Japanese electronics company Sony and the Swedish telecom company Ericsson and has been developing mobile phones since 2001. The main market for Sony Ericsson is Western Europe but the company is constantly growing and is by this date, the number four mobile phone manufacturer in the world. Surfing the internet and playing music are some of the things consumers expect to be able to do with their mobile phones and this makes the question of security a constant factor in software development. Web page certificates are important especially when it comes to internet banking etc and since music in many cases are protected by copyright laws, support for DRM (Digital Rights Management) protected files is necessary. In fact, many mobile phone operators around the world have built their web portals and music services in such a way that they expect phones with support for certificates and DRM protected files. As a major music copyright owner, Sony is obviously also interested in DRM securing music to ensure compensation. As the number of features increase and the technology evolves, the need for security development is ever growing. However, one must always weigh the security enhancement against the cost of performance and usability. The following section will explain more about the task, its background and expectations. The limitations and disposition of the report will also be presented.. 5.

(9) 1.1. Task Definition. Recent years mobile phones have taken on more functions than just connecting audio calls, and as the number of functions have grown so have the number of attacks against them. Especially interesting for an attacker is the DRM protection, but also the certificates used to keep the user safe while surfing the internet is of value for a hacker. A current trend among intruders is to find the private cryptographic keys by using memory logs from run-time. It is easy to find the private keys as they usually are stored as byte arrays in the memory. Part of the thesis work is to modify an AES and MAC algorithm using private keys as input, and to compare the performance. The objective of the thesis work is to: • Study previous work concerning key obfuscation. • Create test cases to examine vulnerabilities in the current implementation. • Modify an AES and a MAC algorithm using split private keys as input. • Compare the performance.. 1.2. Expectations. Our expectations for the thesis work is to have gained a better understanding of the security situation on the mobile phone if keys are handled in RAM. Modified versions of the AES and HMAC algorithms will be created to enable masking of different sorts. We also expect that evaluations, both concerning security and time consumption, of these implementations shall be done after proper measurements and tests.. 1.3. Method. The work was initiated with a study of the environment and applications of the cryptographic algorithms and hash functions on the phones. Different aspects of security were discussed with the employees at Sony Ericsson to lay the basis for the thesis work. Basic knowledge about the different cryptology methods was gathered to make the modifications possible. Studying the threats concerning phones and key handling resulted in the goals and requirements of the thesis work. The concept of masking keys had been prepared by Sony Ericsson and add-on ideas and different types of performance aspects were discussed once the work had started. The masking idea was studied together with previous work done in the area. A test suit was constructed to evaluate the security of the present implementations and to be used when the modifications were ready for testing. The potential security threats found with the initial study of the system became a check-list for the later work. Modifications on the AES and HMAC-SHA1 algorithms were made to implement masking techniques according to the task definition. As the work progressed, the code was tested in emulators running on the computer and later run on the phone to gather time consumption measurements. Last of all, data have been summarized, presented and conclusions drawn to finalize this report.. 6.

(10) 1.4. Limitations. The work presented in this report is that of a M.Sc. degree in electronic design engineering at Link¨oping University and is therefore limited to twenty weeks including the writing of this report. Since the time spent on the work was limited, the report will not go into details about the mathematics of cryptology nor will it include any in-depth studies of DRM or certificates. Even though the report is aimed mainly to an audience that possess some level of knowledge in the concerning area, a few introduction chapters are included to give the reader the basic information needed for further reading.. 1.5. Thesis Disposition. First of all, the background information and some general information about application areas are presented. Where and when cryptology keys are used and the importance of keeping the keys safe is discussed, these sections are for readers with little or no knowledge about mobile phone security. Later on, the current security situation is presented together with information regarding the test suit used to try and extract keys, the results from these tests and how they should be interpreted. The theory of the main work is explained in chapter 7. These sections leads into the actual implementations made and ideas spawned while doing these. In chapter 8 and 9, the enhancements made are presented along with the performance evaluations. Last but not least are the chapters including conclusions and future improvements. In these chapters, chapter 10 & 11, the work is summarized and work that remains to be done is proposed. Some of the chapters include a short introduction section to get the reader up to speed. These introduction sections are intended for the readers who might not be familiar with all the concepts, and experienced readers are recommended to skip these.. 1.6. Background. Many of the products commercially available today contain some form of encrypted or hashed data. It can involve DRM protection, licenses and certificates or identification information. Regardless of what the data is intended for, it is protected for a reason and may be worth a great deal of money to the owner. There are numerous examples of products that have been subject to hacking in the form of simple memory attacks. If the keys are made all too easily extracted, the value of the protected data will soon be lost. Since mobile phones today must be able to do much more than just open and receive phone calls, the phone is in need of many security functions not directly tied to the GSM or UMTS/HSPA system. Most phones today are expected to be able to surf the Internet and therefore a proper certificate handling must be in place. If the user for example wanted to make bank transactions over the phone browser, the browser must be able to ensure the user that it really is the bank he is connected to and that the connection is at least somewhat secure. Another example of functionalities in phones where keys are used is music players. It has become more and more common that mobile phone operators offers music that can be bought through their web portal and downloaded directly to the phone. In these cases the music is often protected using digital rights management or DRM for short. This is done so that the operators can maintain some control over the downloaded files. Since there are economical interests behind the protection, there is also economical gain in hacking these systems. Phone users can be tricked into give attackers access to their bank accounts and software and music could easily be copied, distributed and even sold without the developer’s or artist’s approval. Because there is money to be made, the attackers have more of an incitement to. 7.

(11) hack the product and there are lots of tools at their disposal. Even tools used by the developers can be expected to sooner or later find their way into the hands of the wrong people. Making a system completely secure against all types of attacks is probably impossible, but securing electronic equipment against the most basic attacks could be done by the developers. With a run time attack, the contents of the RAM is copied and searched for sensitive information. This is one of the attacks that the report later on aims to prevent.. 8.

(12) Chapter 2. Background Information 2.1. Digital Rights Management (DRM). The need for rights and restriction management becomes larger and larger when it comes to mobile phone content. Typical phone contents that use DRM protection include ringtones, music files, screensavers, backgrounds and, to some extent, games.. 2.1.1. Open Mobile Alliance (OMA). The main purpose of the Open Mobile Alliance is to ensure service interoperability across devices, geographies, service providers, operators, and networks. [5]. Basically the alliance tries to uphold a level of standardization between the different actors on the mobile phone market. The alliance was formed in 2002 and consists of over 300 member companies including Sony Ericsson. Other large member or sponsor companies include Nokia, Intel, Microsoft, Motorola, IBM and Symbian. To create standardization between actors on the market, OMA has several specification documents that define how services should be set up and used. ”The OMA is designed to be a center for mobile service specification work, stimulating and contributing to the creation of interoperable services” [7] Since there exist a level of standardization on the mobile phone market different operators can offer their services to most of the customers without having to customize its services for every mobile phone brand. As a mobile phone developer, support for services can be developed faster, since there already exist specification documents. This results in a shorter time-to-market for all involved parties. The Open Mobile Alliance is founded on four key principles [6]:. • Products and services are based on open, global standards, protocols and interfaces and are not locked to proprietary technologies. • The applications layer is bearer agnostic (examples: GSM, GPRS, EDGE, CDMA, UMTS). • Architecture frameworks and service enablers are independent of Operating Systems (OS). • Applications and platforms are interoperable, providing seamless geographic and inter-generational roaming. 9.

(13) When it comes to DRM, it is important that the service providers issuing the DRM protected material can be sure that the customer’s phone support the protection mechanism and keeps the content safe. If the providers would have to create different protection mechanisms for each manufacturer the cost of the protection would soon be greater than the value of the protected material. Therefore it is important that there exist standards such as those that OMA has put together.. 2.1.2. DRM. There exist two main versions of OMA DRM, version 1 and 2. The OMA DRM version 1.0 was introduced to market in November 2002 as the demand for means to secure copyright protected material increased. The protection includes different levels that can be used separately depending on the current need. The Forward lock, that prevents the content, often low value content, to be spread from peer to peer. The combined delivery that not only prevents further distribution but also includes a rights object that specifies the usage conditions, and last but not least the separate delivery that is intended to be used with content of higher value. The separate delivery enables superdistribution that allows forwarding of the content but not the rights. In this case the content and the rights object can be delivered through different channels. The protected content is distributed in the DRM Content Format (DCF) which includes a symmetric encryption and a plain-text header for information about the file and encryption. The rights object contains the encryption key or CEK (Content Encryption Key). The key is used by the DRM user agent when accessing the file content.. Figure 2.1: Overview of superdistribution using separate delivery Source: http://www.openmobilealliance.org As the picture in figure 2.1 indicates, the content and the rights object are closely tied together but can be distributed completely separately. And since the content is encrypted with the key contained in the rights object the content is secure and can freely be distributed among the users. The users can later obtain the rights object through the official distributer. This opens up the possibility to distribute files on a large scale and still maintain the control over usage. OMA DRM 2.0 was approved in March 2006 and includes an extension of the separate delivery. 10.

(14) system developed in 1.0. In this extension every device has an individual certificate, a so called DRM Public Key Infrastructure (PKI) certificate, and a private key. The rights objects to be used by the device are protected by encryption using the public key. When the device requires a rights object, it has to register with rights issuer. This often includes payment, and during the registration the certificate is checked against a device blacklist. Thereby the system enables exclusion of hacked devices. This makes the system much more controllable and a leaked certificate cannot cause too much damage.. 2.2 2.2.1. Certificates Message Authentication Codes (MACs). Message authentication codes are used to verify the integrity of a message. A MAC is calculated with the message and a secret key as an input. The MAC is then sent along with the message and the receiver can verify the MAC by calculating a new MAC using the message and key and then compare the MAC with the received one. This will indicate if the message has been tampered with and only people with the key can generate the correct MAC. There are many ways to generate message authentication codes. One of them is the HMAC algorithm, were the MAC is generated using a secure hash function. In this case, the security of the MAC is depending on the strength of the hash function. Usually a hash function is used to generate a unique value or data string for every unique input. This means that the output will only be the same if the input data is the same. The security of a secure hash function is based upon three properties [11]: 1. Efficiency - Computational load of the algorithm. 2. Pre-image resistance - The resistance against recalculation of the message given the hash of that message. 3. Collision resistance - The probability for two different inputs resulting in the same output should be extremely low. The difference between a hash function and the HMAC based on the hash function is that the HMAC function not only takes the data as input but also a key. The HMAC algorithm is defined as followed: HMAC(M, k) = H((k ⊕ opad) || H((k ⊕ ipad) || M )) Where M is the message, k is the key, ipad and opad are constants.. 2.2.2. Signatures. A digital signature is a method to verify the origin of a message. Just as the analogue version it is constructed so that forgery can be detected. The difference between signatures and MACs is that while message authentication codes are made to hinder tampering with the data, signatures verify the sender’s identity. Digital signatures are based upon asymmetrical encryption and to decrease computational complexity hash functions are often used. The procedure works as followed: If Bob wishes to send Alice a message and prove that he is the sender, he uses his private key to create the signature. He then sends Alice the signature, along with the message and when Alice receives the delivery she can use Bob’s public key to verify the signature. She can thereby be sure that Bob signed the message at hand. 11.

(15) The beauty of this system is that anyone with the message, the signature and Bob’s public key can verify that the message is from Bob. However there is no guarantee that Bob really is who he claims to be, only that the person who sent the message is the same person that have distributed the public key. This is where certificates come in.. 2.2.3. Certificates. Certificates or public key certificates as the electronic version is called, are used to identify a person while communicating electronically. This sort of certificates is used mostly while communicating over internet since the origin of data sent over the internet often is impossible to confirm otherwise. Public key certificates are used as a connection between data and a person or company and it is the most common way to establish trust over the internet. Most certificates schemes are set up in such a way that they are signed and validated by a certificate authority (CA) and the validation is often made through a chain of certificates where the user certificate is signed by a registration authority (RA). The certificate of the RA can also be signed by another RA but the chain always ends up at the certificate authority. When the user certificate should be verified, it is checked with the RA and all through the entire chain of RA certificates until the CA verified the last certificate. There also exist other certificate schemes such as PGP, where the certificates are signed by people that know the user. In such a scheme a web of trust is established where the user can trust other users if they have common friends that connects their certificates in this web. Certificates are used widely in secure communications on the internet and internet banking is one of the examples that many people also expect to be able to do on their mobile phone. Therefore the mobile phone manufacturers must offer support for certificates.. 2.2.4. Cryptographic Keys. Whether it is message authentication codes, signatures or certificates that need handling, it always comes down to a key. This key is directly tied to the security of the transmission and if the key is lost or leaked, messages can be forged and/or manipulated along the way. Therefore it is of the outmost importance that the keys are handled and stored safely. Most electronic products that handle keys or other sensitive data store these on a secure file system and the data is often encrypted. Although the keys might be stored safely there is always a risk that there are weaknesses where the keys are used. This is what the thesis work focus on, the handling of keys during runtime and how the security can be improved.. 12.

(16) Chapter 3. Main Threat One of the largest threats to embedded systems today, is the simple yet in many cases effective memory dump. Many electronic products handle sensitive data in plain-text during a small period of time. If an attacker knows when the sensitive data is being used, he or she can always try to perform as many dumps as possible at that specific time. Sooner or later he will be able to extract the information. This is obviously depending on the time that the data resides in the memory, and this is often connected to how the developers and the programming language, handles memory allocations. It might be an allocation that has not been freed, or perhaps have been freed but not overwritten and is thereby still extractable from the memory. When it comes to the C programming language, allocations are not overwritten automatically. If the heap is so large that a former allocation is not likely to be overwritten quickly, the allocation could be overwritten manually before it is freed. Securing the data from this kind of threat is not especially difficult, and just making sure that the developers are careful with how they handle the data will go a long way. Since one can assume that the attackers have full access to the hardware, in this case the phone, other more sophisticated attacks has to be considered. It is also likely that the hacker has access to a large arsenal of applications to aid him and that he has full or partial access to source code and executables that can be disassembled. Combating an attack from this kind of attacker is much harder, and as this report later will discuss, it is most likely just a matter of time and resources before they succeed. The focus of this work has been to create and evaluate methods to secure the cryptographic keys from memory dumps and some types of key logging from inside the system under attack. The goal was to make it as hard as possible to extract the keys, even for those with access to the source code and executables. The report makes no claim of completely securing the keys but tries to discuss the level of security gained and what kind of resources that are needed by the attacker to succeed.. 13.

(17) Chapter 4. Test Suit To examine the security situation in the current implementations, and to evaluate the results of the security enhancements, a test-suit was put together. The test suit consists of six tests, each designed to test a different method that might be applied by a hypothetical attacker and that falls within the focus of the report. The tests were constructed to utilize a post-mortem (crash dump) analyzer for systems running OSE on ARM processors. Some of the tests only consist of plug-ins to the analyzer and performs analysis on the data extracted into dump-files, while some rely on code planted inside the system. Even though these tests were created as plug-ins to the analyzer, it is fully possible to create stand-alone programs that perform these tasks. The advantage of using such an analyzer program is that the development of the tests can be done much faster. The following sections contain short presentations of the tests included in the suit.. 4.1. Memory Iterative Search in Dump-File (MemorySearch). It iterates over the entire memory content in the dump-file, looking for potential keys that match the key description. While being the most common and easily constructed hacking method when it comes to finding keys in every-day electronic products, it is also the most brute-force way that takes a relatively long time and generates a large amount of potential keys. Although it generates many suggestions of keys the list is still heavily reduced, and with only a fair amount of computational power it would be possible to try all the potential keys that it outputs.. 4.2. Allocation Search in Dump-File (AllocInfo). This is designed to search through all variables currently alive in the dump-file using the linking file and it is a more sophisticated version of the MemorySearch test. All potential keys found with this test will also appear in MemorySearch but the number of suggested keys will not be as large. This test will most likely catch every real key that MemorySearch might find, but uses a more intelligent approach that speeds up the process significantly.. 14.

(18) 4.3. Run-Time Eavesdropping (FreeAllocLog). Inserted into the source-code of the phone software, it listens for the free-function calls of memory allocations. It is constructed to determine if allocation may hold potential keys and if so, to save the data so that it later on can be extracted from a memory-dump. This will collect all interesting data saved in allocations that have been freed. A problem with the test is that too many large and interesting allocations in time will fill a small memory. This test complements the previous tests quite well, seeing as how they only find potential keys still residing in the memory while the dump was made, and this test only finds keys previously used.. 4.4. Run-Time Parameter Saving (ParamLog). It is the most sophisticated test in the test suit. It saves the arguments used when security functions such as hashing and encryption functions are being called. This can more or less not fail as pointers to the plain-text keys are passed as arguments. Not all data collected is of interest but there is no random ”junk” data collected by this test. This test is very generic and can be implemented in several functions.. 4.5. Heap Comparison Test. This test extracts the content of the heap from several memory dumps and compares them. If a potential key recurs in several dump-files there is reason to believe that it is a key of some sort. Quite time-consuming but it might be useful when run together with some of the other tests to further distinguish the really interesting findings.. 4.6. Stack Usage (StackLog). This is not a test to extract keys but an attempt to understand how the stack is being used and how often it is over-written. Since the keys or part of the keys at some point are put on the stack it is interesting to see the activity on the stack in order to speculate in how hard it would be to find the key by dumping that part of the memory. It is hard to get any definite answers, and while there are proprietary software products for this kind of study that are far more advanced, this test was put together to give a glimpse of how the stack is used. The StackLog test did not give any information regarding the security-stack. This was most likely due to that the activity on this stack was too low and that the test itself made too much use of the stack. Therefore this test will not be discussed further in this report.. 15.

(19) Chapter 5. Filters In the previous chapter the test suit was discussed, and in most of the tests, the processed data was examined so that the potential keys could be identified. The identification of potential keys is a process where the data is passed through a filter, filtering out data that is not of any interest. Before filtering the interesting key sizes are defined, and in the case of this study keys of size 16, 20 and 256 bytes were of extra interest. In most of the tests, the processed data was given in such a way that only the allocations of these three sizes could be picked out for filtering. In the case of the so called MemorySearch test (sec. 4.1), where all the dump-file data was iterated, the data was sent into the filter 16, 20 or 256 bytes at a time. Therefore, using the MemorySearch test looking for many different key sizes will be very time consuming. The public/private key pairs used in the studied system were in most cases generated using the RSA procedure for key generation. This procedure is done in four steps: 1. Randomly pick two different and very large prime numbers, p and q. 2. Multiply p and q thus getting the product n. 3. Pick an integer, e so that e and (p-1)(q-1) are relatively prime and so that 1 < e < (p − 1)(q − 1). 4. Calculate the integer d that results in e · d ≡ 1(mod(p − 1)(q − 1)). The public key is put together by e and n while the private key is created by d and n. Even if the public key, and thereby e and n, are known, it is impossible to calculate the primes p and q within reasonable time. Since the key is generated by the use of randomly picked numbers, it is likely that the keys display random attributes. Test of randomness performed on keys generated by the RSA algorithm will later be presented, but from now on the keys will be seen as random strings of data. The fact that the keys are fairly random can be used to sort out large quantities of data from the dump-file, since this to a large extent is made up out of trash data. In this case the trash data often consists of block with the same characters repeating over and over. Even in the case of non-trash data, the data often consists of patterns not found in random strings.. 16.

(20) To filter the data, three properties of randomness were checked on the binary strings. 1. A measure of the equality in the number of ones and zeros. So called Sobs value that has a direct connection to the normal distribution. 2. Maximum run length, where the maximum run length in the string is limited. A run is a number of sequential zeros or ones and the run length is the number of sequential bits in a run. 3. Maximum number of runs, where the number of runs that are allowed is limited. This is expressed as a percentage of the maximum number of runs possible, which is the number of bits.. These properties were mathematically analyzed to calculate the statistical probability that a true random string of data would pass the filters. The goal was to pass at least 98% of the random strings through each filter. The calculations are presented in the appendix (A, B and C) and the result of the analysis shows that to achieve 98% let-through of true random strings, the filter parameter should be set as follows: • Sobs to 6. • Maximum run length of the 16 and 20 byte allocations set to 11. • Maximum run length of the 256 byte allocations set to 15. • Maximum runs limit to 60%. The reason that the maximum run length of 256b allocations is set different from the others is that the max run length value varies depending on size, but the difference between 16 and 20b is too small to cause a change. To confirm the calculated parameters for the filters RSA keys were generated. Ten thousand private keys of 16 bytes, ten thousand of 20 bytes and one thousand of size 256 bytes were run through the filters. The data presented in appendix A, B & C shows that the difference between the calculated percentages of allocations let through only differs with about 1% from the measured value. It is clear that reality agrees with the statistical analysis and that the RSA keys do seem random. The outcome of the test is a remarkable good match with the calculations. Put together the filters will filter out a bit more than 2% of the incoming keys but as the following graphs (fig. 5.1, 5.2 and 5.3) shows the parameters will allow approximately 95% through. In these graphs different parameters are used to show the difference they cause in the filtering.. To find out how effective the filter was to discard uninteresting, non-random data from the dumpfile, the allocations caught in the AllocInfo-test (sec. 4.2) were run through. Just as in the previous test when using RSA keys, different parameters were tested. The results are shown in the graphs in figure 5.4 and 5.5. The complete sets of graphs from the tests made on filter parameter are found in the appendix (app. D and E).. 17.

(21) Figure 5.1: 16b RSA private keys, let through filters.. Figure 5.2: 20b RSA private keys, let through filters.. The allocations of size 256 bytes were not put through the filter since the number of allocations were too small. It is enough to look at 16 and 20 byte allocations to see that the filter is working as intended. Obviously, the higher and more generously the parameters are set, the more allocations are let through, and therefore it is important to find a balance in the filtering. It is especially interesting to look at how much passes when the calculated parameters presented previously in this chapter are set. While letting through approximately 90-95% of the keys, the filters manage to sort out over 99% of the 16b allocations and 95% of the 20b allocations from the 18.

(22) Figure 5.3: 256b RSA private keys, let through filters.. Figure 5.4: 16b allocations, let through filters.. memory dump. It is notable that the randomness of the RSA keys becomes clearer as the size of the key grows. The 256b sizes keys are let through in a greater extent than 16 and 20b keys. The conclusion drawn from these tests is that the approximation of the keys as random strings is valid and that the filters perform their task very well.. 19.

(23) Figure 5.5: 20b allocations, let through filters.. 20.

(24) Chapter 6. Current Situation In previous two chapters the filters and the test suit have been presented. In this chapter we will present more information about how the tests were performed and what they revealed. This will give an insight into how cryptographic keys are handled in the tested system and will later lead into the next chapter where the theory behind the proposed solution and upgrade will be discussed.. 6.1. Memory-Dump. The first tests performed were the MemorySearch, the AllocInfo and the heap comparison tests (sec. 4.1, 4.2, 4.5). These are the tests that only depend on the extracted dump-file containing the RAM data. They are the simplest tests of the suit and they are also the most likely methods in an actual attack. The two tests MemorySearch and AllocInfo are more or less the same. The difference is that the AllocInfo test makes use of the map-file for the system and can therefore identify the different allocations that the data is made up of. This means that the search procedure is much more refined, and therefore the time consumed by the search is only a fraction of that consumed by MemorySearch. Considering this fact, and that the two tests both would find the same actual keys made tests with MemorySearch redundant. When it comes to the output of the AllocInfo test (shown in figure 6.1), the number of allocations of the interesting key sizes are summarized. The number of potential keys found are also summarized in the end, which makes it possible to see how many of the allocations of a specific size that passes the filter. It can be useful to study how many potential keys that are found when introducing masks, which will be discussed later.. 6.2. Log Functions. The other test used in the suit rely on code planted inside the target system. They are: FreeAllocLog, that log interesting allocations that are freed, and the ParamLog test. The more interesting of the two types is the ParamLog test. This log function was planted into several of the important functions inside the embedded system. Worth mentioning is the memset function and a couple of HMAC related functions. The memset function is a standard C-function for writing a character to addresses in the memory. The reason that this is of interest is that many programmers use this function for overwriting sensitive data before discarding it.. 21.

(25) (a) Beginning of test printouts.. (b) End of test printouts.. Figure 6.1: Sample printouts from the AllocInfo test. The ParamLog test is generic and constructed so that it can be implemented or planted at any function. The functions chosen in this work are just some of many interesting functions and were chosen as a proof of concept. The ParamLog test will not only collect sensitive data from such a system, it would also give helpful information about how different procedures are made up. By logging arguments in several. 22.

(26) steps, it would be possible to follow the data in its way through the procedure.. Figure 6.2: Sample printouts of ParamLog on memset.. Figure 6.3: Sample printouts of ParamLog on HMAC function.. 6.3. Introduction to Key Handling. One of the goals for this thesis work was to study weaknesses in key handling, weaknesses that makes it possible to extract keys from the memory.. 23.

(27) Many embedded systems store the keys in a protected file system, where the data is encrypted in some way. When the keys are to be used, they are decrypted from the storage. They are thereafter often stored in the memory as plain-text, until they are discarded. The discarding is in many cases done by overwriting the data using the memset function or equivalent, and freeing the allocation. One problem with this procedure is that the keys are handled in plain-text. The tests described earlier exploit this kind of vulnerabilities. The MemorySearch and AllocInfo tests catch the plain-text keys while they exist in the memory. Although, to do this, the attacker must dump the memory content at the right time. By making sure that the time between the decryption and the memset call is minimized, the programmer could make it difficult and time consuming for the attacker to extract the key using this method. This will however not protect the key against attacks similar to the ParamLog test. If the attacker has access to the source code of the system, he can plant functions to log the key as it is passed from the decryption algorithm. This is far more advanced than a simple memory-dump attack, but it is still highly possible if the source code has been leaked from the developer. It should be noted, that if the allocation containing the key is not overwritten before it is freed, there is a bigger risk that the key will be found by tests such as the AllocInfo and MemorySearch.. 24.

(28) Chapter 7. Theory As the goal for the thesis work was put together, there was an idea of implementing a masking scheme for the cryptographic keys to increase security while the keys resided in the memory. This scheme would be implemented in a couple of security algorithms as a proof of concept. The people at SEMC wanted to know how this could be done, the security gained, and an approximation of the time consumption of such a scheme. The algorithms of most interest were the AES encryption/decryption algorithms and the HMAC function. The mask used was supposed to be designed in separate functions so that the modifications of the security algorithms would not need changing if another mask was to be used. This also opens up for easier testing of different masks, which also needed to be done. The idea was to evaluate different masking techniques and to determine the gained security, how much access an attacker would need to extract keys, and how much the different masks cost in terms of execution time. In this chapter, the theory behind masking of keys will be explained and in the following chapters the implementation and the evaluations will be discussed.. 7.1. The Masking Idea. The idea is to somehow distort the data in the keys so that even if the data is extracted, the keys are not usable. Obviously, the distortion must be reversible to enable correct usage of the keys. The data in the keys should be distorted before the key is put into the memory in such a way that only a fraction of the key is handled in plain-text in the memory. In some way this could be seen as applying a cipher on the key but it is in no way supposed to be as secure as an encryption. It is constructed to be easily implemented inside encryption/decryption and other security algorithms using keys, and it is supposed to consume much less time and resources than an encryption would. To enable easy unmasking, the mask is applied with a simple XOR-operator. The advantage of using XOR to apply the mask is that the only thing necessary to reverse the masking, is to once again apply the mask using XOR. XOR is also a basic operator with low processing cost. A very simplified version of the masking procedure using XOR is illustrated in figure 7.1. In reality, the mask must be applied to the key in small segments as the key is decrypted or used. Otherwise the key would still be residing in the memory at some time. The point of masking is that the key never should be found in plain-text on the memory, and that this would secure the system against simple memory dump attacks. Since the function call arguments would not include pointers to an exposed key, attacks such as the ParamLog are prevented as well.. 25.

(29) Figure 7.1: Masking using XOR operator. As the key is masked while residing in the memory, the unmasking procedure must be implemented inside the functions using the key. To gain any security, it is imperative that the key at no point is exposed. Therefore, the key has to be masked at the same time as it is extracted from the secure file system and unmasked just as it is used. As the extractions in many cases, include decryption using the AES algorithm, and as many of the cases where keys are used include AES encryption and signatures, the algorithms chosen for alteration were AES and HMAC. AES encryption is used by the OMA DRM protocol and the HMAC algorithm is used for communicating with, among other things, Bluetooth devices. As mentioned before, the implementation of masking into these algorithms was done to test the concept, and the masking should be possible to apply on any similar algorithms.. 26.

(30) 7.2. Mask Properties. When constructing a mask the following aspects must be taken into consideration: • Computation complexity • Implementation complexity • Memory consumption • Security: – Brute force security gained – Access required for hacking – Level of source code understanding required for hacking – Session uniqueness Computation complexity: The extra time consumption caused by the masking. Implementation complexity: How easy it would be to implement the masking on different ciphers. Memory consumption: How much long-term memory that has to be reserved for the masking procedure. Security: The brute force aspect is probably the easiest aspect to calculate. It is simply the number of tries it would take for someone to guess the mask without having any information about the system to help him or her. The access and source code understanding required more or less speaks for itself. Three levels of access are identified and are presented later on in the Implementation chapter. Session unique masks are important so that a hacker will have a harder time detecting patterns caused by the mask. Since the mask is applied with the XOR operator the attacker can with the help of the mask, unmask all keys distorted with that mask. This is another reason why the key should be changed often. The mask could be unique for each key, for each function or unique for a time-span, and the choice is a compromise between time and memory consumption on one hand and the security on the other.. 7.3. Previous Work. As a part of the thesis work, the previous work done in the key masking area was studied. The idea is not new, but when it comes to masking theories, most of them concern ad-hoc security devices such as Smart Cards. In these works, the look up tables of the AES algorithms are altered to in many cases implement a fixed mask. This is often done to prevent so called side channel attacks such as Power Differential Attacks or PDA for short. In [12] Trichina and Korkishko propose a solution against first order PDA attacks. The solution is based on a hardware module for an AES algorithm. In their proposition the data is masked so that attackers using a PDA would not be able to find any correlation between the input data and the processes inside the system.. 27.

(31) Even though the work has some similarities to the solution proposed here, it is far from the same. The focus of the work presented in this report, is to secure keys from attacks such as memory dump analysis and source code alteration as the argument log test. The solution in this report includes masking that easily can be modified to fit the current need of security. Also, the implementations accounted for herein are made on a system not explicitly constructed for security applications such as the Smart Card.. 28.

(32) Chapter 8. Implementation As mentioned previously, the masking scheme was implemented in the AES and HMAC algorithms. To ensure that as little as possible of the plain-text key can be found in the memory, the masking and unmasking procedure must be implemented inside the algorithms. When the key is needed for an operation such as DRM, the key is decrypted from the secure file system. Since the keys in the secure file system are encrypted with, for example AES, the mask is applied while it is being decrypted by the AES algorithm. To make sure that as little as possible of the key is exposed, the mask is applied to the key one byte at a time. In the case of the AES decryption, the XOR operation applying the mask is made in between other XOR operations that are a part of the original AES algorithm. Due to the properties of XOR this will not alter the masking but it will make the operation more secure as the key data is not exposed at all. If an attacker were to dump the memory content at that time, he could simply extract all the pieces and do the XOR operation himself. But even after all that trouble of timing the memory dumps, he would still not gain more than four bytes of the key. Since the important keys are of a size from 20 to 256 bytes, this would be a very time consuming task, and there are most likely easier ways to hack the product. To make the masking as flexible as possible, the mask byte applied is fetched through a function call. This opens up for the implementation of many different masks without having to alter the AES algorithm further. This also means that the mask could be changed during runtime, thereby increasing security further. Since the focus of this work is not the encryption algorithms, working standard implementations of HMAC and AES were used. The HMAC algorithm was based on SHA1 and it was put together with the code found in rfc2104 [3] and rfc3174 [4]. The AES algorithm used was written by Christophe Devine and is a part of the XySSL package [8]. As the implementations of these algorithms vary, the masking alterations made on the source code will not be discussed in details.. 29.

(33) 8.1. The AES Encryption Algorithm. The AES encryption algorithm is made up of a number of rounds, each round consisting of four operations. The interesting step is the initial adding of the round-key, often called ”AddRoundKey”. This initial step involves a simple bitwise XOR operation made on the data with the initial round-key. The round-keys are made up of the key appended with a couple of expansions made on the key. The expansions are constructed through a couple of steps that distort the key in such a way that masking is not needed on these parts. Masking is although still needed on the first round-key that consists of the encryption key. The unmasking is made in two steps: First of all, the round-keys that are expanded must be generated with the unmasked key. Therefore, the key has to be unmasked one piece at a time inside the key expansion algorithm. The second unmasking is made in the main encryption loop, right after the adding of the initial round-key. Since the first round-key (the encryption key), is applied to the data with bitwise XOR, it does not make any difference if the mask still is present in that part. After the initial round-key has been added, the rest of the round-keys consist of the expanded parts of the key, and have already been constructed using the unmasked key, as mentioned before.. 8.2. The AES Decryption Algorithm. The AES decryption algorithm is basically the same as the encryption, only backwards. While the encryption algorithm is modified so that the input key is masked, the task for the decryption algorithm is different. In this case, it is used when the encryption keys are extracted from the secure file system. Therefore, it is not the input key that needs masking, but the output data. Since the encryption procedure starts with an AddRoundKey procedure, the decryptions ends with one. This means that the mask can be applied to the decrypted data at the point just before the AddRoundKey step. More information about the AES encryption and decryption algorithm can be found at the NIST home page [1]. An illustration of the AES encryption and decryption algorithms with masking implemented as described is shown in figure 8.1. In this picture, the unmasking procedure in the key expansion algorithm for the AES encryption is not included.. 8.3. The HMAC-SHA-1 Algorithm. The HMAC algorithm is depending on an underlying secure hash function. In this implementation, the SHA1 algorithm was used. Since the HMAC heavily depends on the hash function, the HMAC in itself is in no need of unmasking. Changes have been made on the HMAC but they are only there to enable the unmasking in the SHA1 functions called from the HMAC algorithm. The SHA1 is a secure hash function and has no key input. It is the HMAC algorithm that enables the use of keys. This is illustrated in figure 8.2. As the figure also shows, the key is padded with the constants ipad and opad, after which the data and key are inserted into the h-function that represents SHA-1. Therefore, the SHA-1 must enable unmasking of the input data. Just as with many other algorithms constructed to generate random output, the input data is split and combined in different steps, requiring the unmasking to take place quite early in the. 30.

(34) Figure 8.1: Illustration of masking implemented on AES. Source: http://si2.epfl.ch/ gurkayna/acacia/acacia.html (Modified with explanatory text.). process. In the modified version of SHA-1 mentioned earlier, the unmasking is inserted in the SHA1ProcessMessageBlock function in such a manner that the data is kept safe.. Figure 8.2: Illustration of HMAC. Source: http://en.wikipedia.org/wiki/HMAC. 31.

(35) 8.4. General Implementation of Masking. The implementations mentioned in previous sections are used as examples. The masking idea is supposed to be more general than to only be applied on AES and HMAC. The point is that the masking and unmasking must be done so that the sensitive data never is exposed. In all three algorithms mentioned, the entire masking and unmasking process is made so that no piece larger than one byte of the mask at any point is revealed. In all these cases, the masking/unmasking is made just before or after an inherent bitwise XOR operation so that the key even after unmasking, is kept safe until it is discarded.. 8.5. Masks. The modifications of the AES and HMAC algorithms were made so that the choice of mask could be made outside these functions. The choice of mask is a balance between security and time consumption. To evaluate different masks, a set of six masks was put together and tested. They vary from very simple to quite complex and fully usable. The intention of these masks was not to determine and finalize which mask that should be used in this sort of system. The intention is to give the reader some ideas of how the masks could be constructed and to give a hint of the security aspects as well as the computational complexity. The list of considerations when constructing the masks is presented in the theory chapter 7.2. The masks constructed in this work are these: 1. Fixed value - A fixed predefined character value applied over and over. Not intended for real use but it gives a good reference point to the other masks. 2. Fixed array - A fixed predefined array of characters. If the array is smaller than the key, as it often is, the array is used cyclically. 3. Random alloc - The character values are randomly generated, put into a randomly allocated memory slots and arranged in an array according to an array permutation. The array is applied as the previous mask. 4. Random alloc with function pointers - The same as the previous mask but instead of the values put into the array in a permutated order, function pointers to functions returning the values, are inserted. More information about this will be presented later. 5. Random alloc without permutation - Randomly allocated random numbers in an array. The permutation step has been removed to show if the step causes much time consumption. 6. Random seed - Using a predefined seed, the mask generates random numbers on the fly. This is more time consuming then the others as the calculations are made as the mask is used, while the others are initiated once and then saved. The upside is that this mask does not need as much space. The most interesting masks are the last four. The first two should be seen as references in the performance tests. The random seed mask is of a different nature then the others. It only relies on an integer as a seed. This means that it only takes up four bytes of extra memory but will instead cause more computations and therefore take more time. The security is questionable since an attacker only need 32.

(36) to know which randomization-function is used and extract the seed. The random allocation mask represents different steps in the evolution of the third mask type listed above. When using an array as a mask it is natural to use random numbers, as these will be harder to detect inside the memory. If the array was saved as one continuous piece in the memory, it would be easy for a hacker that knows of the mask implementation to extract the masked key and the mask, with help from code described in the MemorySearch test section (sec. 4.1). To make it a bit harder, the arrays are put together with pointers to random allocations containing the mask values. In the case of mask 3 and 4, the pointers are put into the array with the help of a permutation to gain extra obscurity. The different masks require the hacker to have different knowledge of the system. The fixed array mask more or less only requires knowledge about the mask and that it is applied with XOR. When it comes to random alloc, the hacker needs access to the linker file to be able to find the array. If function pointers are used, the hacker also needs the executable of the system to connect the function pointers to functions and mask values. Permutation requires extraction of yet another array from the memory, thereby increasing the number of ”guesses” for the hacker once all the right sized arrays have been extracted. If a mask such as the fixed array is used it is interesting to see how many allocations of the mask size that exist in the memory. If there are too few allocations it will be easy for an attacker to find the mask. As mentioned in section 6.1 - Memory Dump, the AllocInfo test can output the number of allocations of specific sizes, and it can also output the number of allocations that passes the filters for each size. This will show how well the mask is hidden in the memory.. 33.

(37) Chapter 9. Results As explained briefly in the mask section earlier (sec. 8.5), the most basic mask constructed from a fixed character value is, of course, not hard to circumvent. It is enough for the attacker to know that the masking exists and to brute-force attack the system by simply trying all possibilities. The fixed array mask does not offer much more security either. It can be assumed that if it only comes down to a couple of extra million possibilities, the system will soon be cracked. The computational power of computers today will make the story short with that sort of security, and it can also be assumed that the processing power of computers will increase just as it has done the last couple of years. Even if the development today does not follow Moore’s law [2], it should be considered when dimensioning the security enhancement. During the development of the masks tested in this thesis work, three security steps were identified. The steps represent different levels of access to the system and the source code needed for the attacker to extract keys. The steps identified were: 1. Basic knowledge about the security implementations in the system and some access to the source code. 2. Access to the linker file/files for the system. This will enable more intelligent data sorting of the memory content extracted from the memory dump-file. 3. Access to the executable. This enables disassembly and some back tracing of function calls etc. This requires quite a lot of knowledge about system attacks and hacking. If the masks were categorized according to these steps the two masks with fixed values and the random seed mask, would only require the first step. The second step would speed up the process but would probably not be necessary. The random allocation masks are more complex. They would require quite a bit of source code knowledge and most likely the linker file. The linker file is probably needed since the random allocation pointers in the array would make the array much harder to find by guessing. As the function pointers are added, the last level of access is needed. To be able to know what the functions pointed to by the array will return, the function addresses and content would have to be studied. By this point there is not much to gain from increasing the complexity of the mask since the keys probably could be extracted some other way with less work involved.. 34.

(38) The different masks described earlier were tested and their time consumption measured. The test was set up so that the whole process of encryption/decryption and MAC generation respectively, were iterated one thousand times. Therefore, the value does not depend so much on the other processes that might be active on the phone at the same time. To give a perspective on the test results, the implementations were run without masking as well as with all the masks presented earlier. Some implementations that existed in the original phone system were also tested, and the measures on those will stand as point of reference to the mask implementations.. 9.1. AES Decryption. In figure 9.1(a), the current implementation of the AES decryption in the system has been tested, and in figure 9.1(b), the implementation later used for mask modifications is run. Below the two is a comparison in which it is clear that the SEMC algorithm is faster. The fact that it is faster is quite expected, since the algorithm shown in 9.1(b) is a standard implementation not developed for high performance on an embedded device. If it had been faster, there had been cause for concern regarding the SEMC implementation. The measurement on the SEMC implementation was not done to check the optimization but to compare it to the XySSL implementation and approximate how much time consumption masking would cause on the SEMC algorithm. Approximations of the line equations are found to the right in the graphs. They are in the form of y = mx + b, and these represent the equations for the 20b and 256b key. The y-intercept value b is an approximation of time consumption for very small quantities of data, and the so called gradient m gives us an indication of how much the time consumption depends on the data processed. The equations can be used to compare the performance of different implementations more easily. Results from introducing masks are shown in figure 9.2. Here, the initiation of the masks is not included since the mask should be generated only once or perhaps a few times during run-time. Please note that the Y-axis in the random seed test is in 10 ms and not ms as the others. This shows that the kind of heavy computations made while generating random number on the fly, is not an option on this system.. There is a clear difference between the masks. If one does not include the random seed mask, the two extremes are the random allocations mask with function pointers and the fixed value mask. Looking at the equations for 256b key size; y=1.4x+28.2 for the fixed value mask and y=2.1x+21.0 for the random alloc with function pointers. Keep in mind that the measurements were made with 1000 iterations. If we for example look at the case where keys are decrypted from the secure file system, the processed data will be approximately the size of the keys. The time consumption, when using a fixed mask while decrypting a 256b data block (a key), will be around 2.9 ms compared to 4.3 ms using a random allocation with function pointers. The difference is not that large when it comes to a single operation, but more interesting is perhaps the extra time caused by the mask in respect to the unmasked algorithm. In figure 9.1(b), the 256b key operation without using a mask is approximated y=1.3x+29.0. Compared to the previous mentioned equations, the added time consumption is 2.9-2.7 = 0.2 ms with fixed value mask, and 4.3-2.7 = 1.6 ms for function pointer mask. Since the extra time consumption does not depend on the encryption function implementation, this execution time add-on will be more or less 35.

(39) (a) Implementation found in original system.. (b) The XySSL implementation without mask.. (c) The two implementations compared.. Figure 9.1: Time comparison between AES decryption algorithms. constant. Therefore it would be safe to assume that the extra time consumption will be the same for the SEMC implementation. Calculating the add-on for the SEMC algorithm gives it an increase about 10% when using fixed mask, and 80% increase for the function pointer mask.. 9.2. AES Encryption. The masking on the encryption is a bit more complex, and consequently has a higher time consumption. Despite this, the extra time for using the best mask tested in this report is not that large, and the implementation should be considered. The extra time consumption for the encryption algorithm encrypting 256 bytes, using a 256 byte large key when implementing masking, is increased about 0.6 ms for fixed mask and 3.0 ms for the function pointer. Applying this to the SEMC implementation would, according to the previous reasoning, give an increase of 30% and 150% respectively. Keep in mind that this is approximations and could probably be tweaked for increased performance. Since the extra time consumption is fairly large, the level of masking should be chosen depending on how many encryption operations that are performed and how important the key is. As seen in both figure 9.2(f) and 9.4(f), the random seed mask is unusable on the phone since it would take too much extra time. The mask is still interesting though, since it offers a different type of implementation, where the mask is not to be found in the memory. It is possible that the time consumption of the mask could be lowered by trying different types of randomization algorithms, so that the advantages of such a mask make it interesting for implementation.. 36.

(40) (a) Fixed value mask.. (b) Fixed value array mask.. (c) Random allocation mask.. (d) Random allocation mask without permutation.. (e) Random allocation mask with function pointers.. (f) Random seed mask.. Figure 9.2: Time consumption using masks on AES decryption.. 9.3. HMAC-SHA1. When it comes to the HMAC algorithm, only the fixed mask is tested. It can be assumed that the difference in time consumption between the mask types is the same as in the AES implementations. The graphs in figure 9.5 show the difference between implementations.. 37.

(41) (a) Implementation found in original system.. (b) The XySSL implementation without mask.. (c) The two implementations compared.. Figure 9.3: Time comparison between AES encryption algorithms.. 38.

(42) (a) Fixed value mask.. (b) Fixed value array mask.. (c) Random allocation mask.. (d) Random allocation mask without permutation.. (e) Random allocation mask with function pointers.. (f) Random seed mask.. Figure 9.4: Time consumption using masks on AES encryption.. 39.

(43) (a) Implementation found in original system.. (b) The RFC implementation without mask.. (c) The RFC implementation with fixed mask.. (d) SEMC vs. RFC implementation.. (e) RFC vs. RFC with mask.. Figure 9.5: Time comparison between HMAC-SHA1 algorithms.. 40.

(44) Chapter 10. Conclusions As the report has shown, it is fully possible to implement masking in different security functions to secure the keys while residing in the memory. It has also been shown that the masking prevent hacking in the form of memory dump analysis and simple source code alterations. In fact, the masking will prevent all of the tests in the test suit developed from extracting keys, although the masking procedure was partly developed with consideration to flaws exploited by the tests. Masking the keys will increase the time it takes for attackers to extract keys. How much extra time it results in depends on the masking, and on the level of access to the system that the attacker has. Please keep in mind, that other flaws in key handling have not been studied, and increased masking security does not guarantee increased overall memory dump security on the embedded system. As mentioned in section 6.2, it is important that developers are aware of how the system handles memory, and that sensitive data is discarded properly after use. Even though masking of the keys would keep them relatively secure even if they are found in a memory dump, the security will be increased if keys are handled correctly. Simple security test such as those in the test suit chapter (chap. 4), can be enough to find security flaws. It is probably a good idea for developers to try and attack their own phones from time to time, thereby testing their systems and getting a better understanding of how the hackers think. It can be seen in the Results section, that the increase of time consumption of the algorithms when masking is implemented, is not especially large for each operation. But it has to be considered that the operations might be performed many times during a simple task such as music playback etc. The question is if the user is willing to sacrifice perhaps a few seconds for the increased security. This is the core question that the security architects needs to answer. Since different masking methods also result in different amounts of time consumption, different masks could be used from time to time depending on the security need. Some keys might not even need masking and in such a case the masking could be turned off, thus removing the extra time consumption.. 41.

(45) The security add-on and the performance loss it causes should also be proportional to the value of the keys that it protects. The measurements done in this report have been done on a modern embedded system, but as processors evolve, the computational power will increase and the performance loss of masking will decrease.. 42.

(46) Chapter 11. Future Improvements There are a few things that need to be studied before a large scale implementation of masking in mobile phones would be feasible. One of them is the boot up sequence, and if there is room for the extra execution time. The booting of the phone system requires a lot of computations, and since the amount of extra time that the masking adds to the boot-up is uncertain, there might be problems when masking is introduced. The added execution time as well as the increased security of the masking should be reevaluated as the hardware changes. Not only do considerations for the masked system have to been taken, but also for the increased capabilities of an attackers due to increasing processor power. How the key masking/unmasking is done is also very important to study. Even though the implementations in this report are relatively safe, it is hard to foresee how the algorithms will manipulate the data after it has been unmasked. Perhaps the key is exposed again later on in the process, and if the attacker is well familiar with the algorithms he might be able to extract the key or parts of it. The usage of the encryption algorithms in operations such as DRM is important when it comes to calculating the overall effect of the time consumption due to masking. One encryption procedure using a masked key might only result in a millisecond delay but what will happen if there are hundreds of encryptions done? Another interesting aspect is if it is possible to gain time by letting frequently used keys lie masked in the memory, instead of extracting them from the secure file system every time they are used. The question is then how much of a security threat this is, and how many times the key has to be used before the gain is noticeable. Finally, when all security and performance aspects have been studied and discussed, the masking must be implemented on the algorithms used by the system. The algorithms used for this report were, as mentioned previously, standard algorithms not created for use on this sort of embedded system, and were therefore not as fast as those already present.. 43.

No results found