Applying Attribute-Based Encryption in Two-Way Radio Talk Groups: A Feasibility Study

Transcription

1 Brigham Young University BYU ScholarsArchive All Theses and Dissertations Applying Attribute-Based Encryption in Two-Way Radio Talk Groups: A Feasibility Study Michael Andreas Gough Brigham Young University Follow this and additional works at: Part of the Electrical and Computer Engineering Commons BYU ScholarsArchive Citation Gough, Michael Andreas, "Applying Attribute-Based Encryption in Two-Way Radio Talk Groups: A Feasibility Study" (2018). All Theses and Dissertations This Thesis is brought to you for free and open access by BYU ScholarsArchive. It has been accepted for inclusion in All Theses and Dissertations by an authorized administrator of BYU ScholarsArchive. For more information, please contact scholarsarchive@byu.edu, ellen_amatangelo@byu.edu.

2 Applying Attribute-Based Encryption in Two-Way Radio Talk Groups: A Feasibility Study Michael Andreas Gough A thesis submitted to the faculty of Brigham Young University in partial fulfillment of the requirements for the degree of Master of Science James K. Archibald, Chair Doran K. Wilde Jeffrey B. Goeders Department of Electrical and Computer Engineering Brigham Young University Copyright c 2018 Michael Andreas Gough All Rights Reserved

3 ABSTRACT Applying Attribute-Based Encryption in Two-Way Radio Talk Groups: A Feasibility Study Michael Andreas Gough Department of Electrical and Computer Engineering, BYU Master of Science In two-way radio systems, talk groups are used to organize communication. Some situations may call for creating a temporary talk group, but there are no straightforward ways to do this. Making a new talk group requires programming radios off-line. Temporary groups can be created, but this requires inputting radio IDs which is tedious on a radio s limited controls. By describing group members using attributes, ciphertext-policy attribute-based encryption (CP-ABE) can be used to quickly create sub-groups of a talk group. This scheme requires fewer button presses and messages sent in the new talk group are kept secret. CP-ABE can be used on deployed hardware, but performance varies with the type of embedded processor and the number of attributes used. Because radio communication is time-critical, care must be taken not to introduce too much audio delay. By using benchmark programs on a variety of single-board computers, we explore the limits of using CP-ABE on a two-way radio. Keywords: encryption, two-way radio communication, attribute-based encryption, embedded hardware, talk groups

4 ACKNOWLEDGMENTS The author would like to thank his parents, brothers, and friends both in school and abroad for offering motivational support through his academic studies. He would also like to thank his committee chair for counseling on the thesis topic and for the opportunity to work as a research assistant.

5 TABLE OF CONTENTS List of Tables vi List of Figures vii Chapter 1 Introduction Talk Groups on Two-Way Radios Using CP-ABE Applying CP-ABE to Talk Groups Proposed Systems The Naïve System A System That Pre-Generates CP-ABE Keys A System That Reuses AES Keys Key Management CP-ABE Performance on Radios Reasoning for Using Single Board Computers Chapter 2 Theories and Concepts Two-Way Radio Systems Land Mobile Radio Standards Radio System Architecture Attribute-Based Encryption Origin of Attribute-Based Encryption ABE Schemes ABE Fundamentals Advanced Encryption Standard History of AES AES Implementation Block Cipher Modes Related Work CP-ABE Applications CP-ABE Performance Chapter 3 Methods and Implementation Tested Devices CP-ABE Benchmark CP-ABE Implementations Modifications to the cpabe Toolkit Attributes for the Benchmark Expected Outcomes OpenSSL AES Benchmark AES Benchmark Settings Hardware Specific Benchmarks iv

6 3.3.3 Acceptable AES Performance for Audio Test Plan Summary Chapter 4 Results and Analysis CP-ABE Performance Raspberry Pi 1B and Clock Speed Effect of Multiple Cores Results at 1GHz and Architecture Comparison CP-ABE Results Analysis AES Performance AES Software Performance AES Software Performance at 1GHz AES Multi-Threaded Performance AES Cryptographic Core Performance AES Results Analysis Chapter 5 Observations CP-ABE on Hardware in the Field User Interface Attribute Limits Applying Performance Improvements Low-Cost Accessory New Radio Devices Chapter 6 Conclusions and Future Work Our Contributions Future Work References Appendix A CP-ABE Benchmark Code v

7 LIST OF TABLES 3.1 Single board computer specifications Test plan summary Single board computer specifications AES processor utilization recorded using GNU Time vi

8 LIST OF FIGURES 1.1 Use of functions in an example CP-ABE system Using CP-ABE on a two-way radio Encrypting and decrypting audio messages using CP-ABE in a two-way radio Naïve CP-ABE encryption scheme on two-way radios Pre-generated CP-ABE encryption scheme on two-way radios AES key reuse on two-way radios Simplex operation of a two-way radio system Repeater operation of a two-way radio system Trunked operation of a two-way radio system AES scheme outline AES byte substitution AES shift rows AES mix columns AES round key Electronic codebook mode Cipher block chaining mode Output feedback mode Counter mode AES benchmark output example Average CP-ABE encryption time vs. number of attributes Average CP-ABE decryption time vs. number of attributes Average CP-ABE encryption time vs. number of attributes using a 1GHz clock Average CP-ABE decryption time vs. number of attributes using a 1GHz clock AES CBC benchmark results AES CTR benchmark results AES software benchmark comparison AES 1GHz benchmark comparison AES multi-threaded benchmark comparison AES cryptographic hardware benchmark comparison Interface of a typical two-way radio vii

9 CHAPTER 1. INTRODUCTION 1.1 Talk Groups on Two-Way Radios In conventional two-way radio, voice messages are categorized based on the information carried [1]. These are known as talk groups and allow organization in communication. A simple system may have a dispatch group, an information group, and a chat group. A dispatch talk group is used for assigning tasks to field operatives. An information group is used for situation updates and answers to questions in the field. A chat group is used for general discussion without disturbing other talk groups [1]. To send or receive messages in a talk group, a user must join the group by selecting it on their two-way radio. When a message is sent on a talk group, all members in the group receive the message [1]. In some situations, it is desirable to send messages to a subset of the group. Modern radios allow the creation of temporary groups, but this can be cumbersome in the field. Each radio must be selected based on ID using limited controls on the front panel [2]. One solution would be to create a new talk group, but this requires off-line programming [2]. Adding groups cannot be created easily on-the-fly. Transmitted messages can also be intercepted by third parties. If the discussion is of a sensitive nature, the broadcast should be encrypted so malicious entities cannot hear it. To more easily create subgroups and improve security in talk groups, we suggest applying Ciphertext-Policy Attribute-Based Encryption (CP-ABE). In CP-ABE, private keys are created using attributes describing the user. When encrypting, an access policy dictates the attribute combinations that can decrypt the ciphertext. If the private key attributes satisfy the access structure, the plaintext is recovered [3]. 1

10 1.1.1 Using CP-ABE CP-ABE has advantages over other cryptographic systems. Each individual has a unique key to decrypt messages, so if an adversary obtains a key the damage is limited [4]. Only ciphertexts with access policies satisfied by the stolen key are decrypted. By contrast, the loss of a key in a shared key system results in all messages being insecure [5]. CP-ABE maintains flexibility compared to other systems where each user has a unique key. Instead of requiring that each message be re-encrypted for each private key, messages only need to be encrypted once using the public key [4]. An attack on key-based systems involves mathematically analyzing and combining keys to produce a new key, known as collusion. CP-ABE by design is collusion resistant. If an adversary has a set of keys, they cannot be combined to produce a new key with all the set s attributes [3]. To better understand these advantages and how CP-ABE might be used, consider a fictional police department covering the three cities Citytowne, Urbapol, and Metrovillage. The department is divided into several groups, presided over by a chief. In recent months, there has been an increase in drug trafficking and the police chief suspects a police unit in Urbapol is facilitating the movement. The chief decides to implement a CP-ABE system to keep messages secret within the department. During system initialization, a public key and master key are generated using the setup function as shown in Figure 1.1a. The public key is used for encryption and sent to all officers in the department. The master key is kept secret and only used for the generation of private keys for each member of the department [3]. Attributes are not defined during the setup function. Instead, attributes are added to the system when creating private keys. A new attribute can be added to the system without needing to regenerate the public or master key. Only existing private keys that require the new attribute need to be regenerated. To generate a private key, the attributes (new or existing), the master key, and the public key are passed into the key generation function (shown in Figure 1.1). Keys are managed by a trusted authority which has power to generate new keys, refresh expired keys, and revoke keys in the system. A message detailing an upcoming Citytowne drug bust is encrypted with the access policy Police Chief OR Drug Enforcement AND Citytowne which is seen in Figure 1.1c. The police chief decrypts the message with his private key. The decryption is successful because his key was 2

11 Attributes (Unit 0451, Drug Enforcement, Citytowne) Public Key Master Key Access Policy (Police Chief OR Drug Enforcement AND Citytowne) Public Key Message Setup Key Generation Encrypt Public Key Master Key Private Key Ciphertext a) b) c) Private Key (Unit 0451, Drug Enforcement, Citytowne) Public Key Ciphertext (Police Chief OR Drug Enforcement AND Citytowne) Private Key (Police Chief, Metrovillage) Public Key Ciphertext (Police Chief OR Drug Enforcement AND Citytowne) Decrypt Decrypt Message Message d) e) Private Key (Unit 0042, Drug Enforcement, Urbapol) Public Key Ciphertext (Police Chief OR Drug Enforcement AND Citytowne) Decrypt Null f) Figure 1.1: Use of functions in an example CP-ABE system [3]. a) A setup function produces the public and master keys. The public key is used for encryption, and the master key is used to generate private keys. b) Creation of a private key using the public and master keys and the attributes Unit 0451, Drug Enforcement, Citytowne. c) Encryption of a message using the public key and an access policy of Police Chief OR Drug Enforcement and Citytowne. d) and e) Successful recovery of the message using the private and public keys and the ciphertext. The attributes associated with the private keys fulfill the access policy of the ciphertext. f) Unsuccessful decryption of the ciphertext since the attributes associated with the private key do not fulfill the access policy of the ciphertext. 3

12 CP-ABE Public Key Selected Attributes Receiver CP-ABE Encryption AES Key CP-ABE Ciphertext RF CP-ABE Private Key CP-ABE Public Key CP-ABE Ciphertext Transmitter CP-ABE Decryption AES Key Transmitting Radio Receiving Radio Figure 1.2: Using CP-ABE on a two-way radio. The CP-ABE public key and selected attributes are used to generate an AES key and a CP-ABE ciphertext. The ciphertext is transmitted over RF. If the receiving radio s private key satisfies the encryption attributes, the AES key is recovered. Both radios now have a common AES key. created with the attributes Police Chief, Metrovillage. Unit 0451 also successfully decrypts the message with his key that has the attributes Unit 0451, Drug Enforcement, Citytowne [3]. The plaintext recovery for the chief and Unit 0451 using the decryption algorithm is seen in Figure 1.1d and Figure 1.1e respectively. A Drug Enforcement agent, Unit 0042 from Urbapol, is enabling the illegal movement of drugs to Citytowne. He wishes to decrypt the message to alert his dealers of the bust. Unit 0042 s key was created with the attributes Unit 0042, Drug Enforcement, Urbapol. Since his attributes do not satisfy the access policy, the message is kept secret as demonstrated in Figure 1.1f where the decryption algorithm returns null. He obtains an additional key from the Special Victim s Unit in Citytowne with attributes Unit 1830, SVU, Citytowne. While this key does not decrypt the message either, Unit 0042 hopes that by analyzing both keys he is able to fabricate a key that can. Due to the collusion resistant nature of CP-ABE, this is also unsuccessful [3]. 4

13 Audio Audio Buffer Receiver AES Key Audio Segment AES Key AES Ciphertext AES Encryption RF AES Decryption AES Ciphertext Audio Segment Transmitter Audio Buffer Audio Transmitting Radio Receiving Radio Figure 1.3: Encrypting and decrypting audio messages using CP-ABE in a two-way radio. After a common AES key is established on both radios, the encrypted audio message can be streamed. 1.2 Applying CP-ABE to Talk Groups Our proposed approach, shown in Figure 1.2, uses CP-ABE to establish an AES key for message transmission. This is like the proof-of-concept program created by Bethencourt et al. where an AES key is generated along with the ciphertext [6]. This CP-ABE ciphertext is received by all users who have selected the talk group, but the AES key is recovered by the subset who have the required attributes. This effectively creates a new talk group. This AES key is used to encrypt and transmit audio segments over RF which is demonstrated in Figure 1.3. Radios with keys satisfying the access structure decrypt and play the audio segments, ideally with minimal delay. Applying CP-ABE to radio allows talk groups to be easily created in the field. By selecting attributes, several radios can be included (or excluded) from the new talk group. This translates to fewer button presses on a radio allowing quick creation of talk groups. All messages created using CP-ABE are encrypted. Transmissions will be protected from other users on the system and eavesdropping third-parties. Each user has a unique CP-ABE key as opposed to a common group key. CP-ABE is also collusion resistant. If a malicious party obtains several private keys, they are only able to decipher data related to those keys. Other keys in the 5

14 Step 1: Radio A generates CP-ABE Ciphertext and AES key Step 2: Radio A transmits CP-ABE Ciphertext Step 3: Radio B successfully decrypts CP- ABE Ciphertext Radio A CP-ABE Ciphertext AES Key Radio A CP-ABE Ciphertext AES Key Radio A CP-ABE Ciphertext AES Key CP-ABE Ciphertext Radio B Radio B CP-ABE Ciphertext Radio B CP-ABE Ciphertext AES Key Step 4: Radio A transmits message blocks encrypted in AES Step 5: At end of message, AES key and CP-ABE Ciphertext are discarded Radio A CP-ABE Ciphertext AES Key Radio A CP-ABE Ciphertext AES Key AES Encrypted Message Blocks Radio B CP-ABE Ciphertext AES Key Radio B CP-ABE Ciphertext AES Key Figure 1.4: Naïve CP-ABE encryption scheme on two-way radios. CP-ABE is used to encrypt an AES key. This CP-ABE ciphertext and AES key is used only for this message and discarded. system cannot be derived by mathematically analyzing the compromised keys [3]. In addition, several key management schemes have been proposed for key revocation [7] [4]. 1.3 Proposed Systems In this section, we give examples of complete radio systems based on CP-ABE. We describe the naïve system in Section 1.3.1, a system using pre-generated keys in Section 1.3.2, and a system that reuses keys in Section We also describe a key management scheme in Section The Naïve System The simplest system begins with the user selecting the attributes for a new CP-ABE group on the radio. These attributes will be used to create a new talk group with a subset of members from the currently selected talk group. The user presses the transmit key on the radio which causes an AES key to be generated and encrypted using CP-ABE, shown as Step 1 in Figure 1.4. The CP-ABE ciphertext is sent to all members of the currently selected talk group (Step 2) but is decrypted only by those who meet the defined attributes (Step 3). Radio A then encrypts the audio 6

15 message using the AES key and transmits the encrypted blocks, shown in Step 4. These blocks are decrypted by receiving radios with the AES key. After the message is complete in Step 5, the CP-ABE ciphertext and the corresponding AES key are discarded. The access policy used for CP-ABE encryption should be included as part of the AES encrypted message. This will be saved by radios that successfully decrypt the CP-ABE ciphertext. This way the new talk group can be added as a selection in the talk group list on all radios and future messages will be transmitted using the same policy. This also covers the situation where a radio with matching attributes is not monitoring the talk group when the first message is sent. Using the access policy, they will be able to add the new talk group to the list of talk groups and send encrypted replies. Any radio monitoring the talk group and not fulfilling the access policy fails at decrypting the CP-ABE ciphertext. Because a CP-ABE ciphertext is sent in every encrypted message, these radios will repeatedly attempt decryption. To avoid this unnecessary effort, the access policy can be sent in plaintext before every message. Radios can then determine beforehand if decryption will be successful. The drawback to sending the access policy in plaintext is the message recipients are no longer anonymous. This information can be used to attack radios that are known to have matching keys. This system is very secure because a new CP-ABE ciphertext and AES key is used for each message, but this incurs a large delay. We define delay in this system as the difference in time from the transmitting user pressing the transmit button to the receiving users beginning playback of the message. For a naïve system, the delay is equal to the time taken to generate the CP-ABE ciphertext and the first AES ciphertext on the transmitting radio, plus the time taken to decrypt the CP-ABE ciphertext and first AES ciphertext on the receiving radios. There is also a delay incurred for transmitting the data over RF. Because this delay is relatively minor, we only focus on the delay from encrypting and decrypting messages [8] A System That Pre-Generates CP-ABE Keys Part of the delay in the naïve system can be reduced by generating AES keys and encrypting them using CP-ABE while the system is not in use. As shown in Figure 1.5, several keys can be created, encrypted, and stored in memory in anticipation of their potential use. These keys are all 7

16 AES Encrypted Message Blocks Step 1: Radio A generates CP-ABE Ciphertexts and AES keys Radio A CP-ABE Ciphertext 1 AES Key 1 CP-ABE Ciphertext 2 AES Key 2 CP-ABE Ciphertext n AES Key n Radio B Step 4: Radio A transmits message blocks encrypted in AES using AES Key 1 Radio A CP-ABE Ciphertext 1 AES Key 1 CP-ABE Ciphertext 2 AES Key 2 CP-ABE Ciphertext n AES Key n Radio B CP-ABE Ciphertext 1 AES Key 1 CP-ABE Ciphertext 1 Step 2: Radio A transmits CP-ABE Ciphertext 1 Radio A CP-ABE Ciphertext 1 AES Key 1 CP-ABE Ciphertext 2 AES Key 2 CP-ABE Ciphertext n AES Key n Radio B CP-ABE Ciphertext 1 Step 5: At end of message, AES Key 1 and CP-ABE Ciphertext 1 are discarded Radio A CP-ABE Ciphertext 1 AES Key 1 CP-ABE Ciphertext 2 AES Key 2 CP-ABE Ciphertext n AES Key n Radio B CP-ABE Ciphertext 1 AES Key 1 CP-ABE Ciphertext 2 Step 3: Radio B successfully decrypts CP-ABE Ciphertext 1 Radio A CP-ABE Ciphertext 1 AES Key 1 CP-ABE Ciphertext 2 AES Key 2 CP-ABE Ciphertext n AES Key n Radio B CP-ABE Ciphertext 1 AES Key 1 Step 6: Radio A transmits the next CP-ABE Ciphertext, Steps 3-6 are repeated Radio A CP-ABE Ciphertext 2 AES Key 2 CP-ABE Ciphertext n AES Key n Radio B CP-ABE Ciphertext 2 Figure 1.5: Pre-generated CP-ABE encryption scheme on two-way radios. Multiple AES keys are generated, encrypted using the attributes for the new talk group, and stored for future use. The ciphertext generation can be performed while the radio is idle. Each CP-ABE ciphertext and AES key is used once per message and discarded. encrypted using the attributes used to define the new talk group. This method removes the CP- ABE encryption from our definition of delay, leaving only the time taken to encrypt the first AES ciphertext, the time taken to decrypt the CP-ABE ciphertext, and the time taken to decrypt the first AES ciphertext. As in the naïve system, the CP-ABE access policy should be AES encrypted and transmitted with each message. This will allow radios that fulfill the access policy to add the new talk group to their list of talk groups and reply using the same policy. This includes radios not monitoring the talk group during the first message. This system will take more coordination, as all radios in the new talk group need to pre-generate several CP-ABE ciphertexts and AES keys to reply. 8

17 Step 1: Radio A generates CP-ABE Ciphertext and AES key Step 2: Radio A transmits CP-ABE Ciphertext Step 3: Radio B successfully decrypts CP-ABE Ciphertext Radio A CP-ABE Ciphertext AES Key Radio A CP-ABE Ciphertext AES Key Radio A CP-ABE Ciphertext AES Key CP-ABE Ciphertext Radio B Radio B CP-ABE Ciphertext Radio B CP-ABE Ciphertext AES Key Step 4: Radio A transmits message blocks encrypted in AES Step 5: Subsequent messages are encrypted using the AES Key and transmitted Radio A CP-ABE Ciphertext AES Key Radio A CP-ABE Ciphertext AES Key AES Encrypted Message Blocks AES Encrypted Message Blocks Radio B CP-ABE Ciphertext AES Key Radio B CP-ABE Ciphertext AES Key Figure 1.6: AES key reuse on two-way radios. After the key is transmitted to each radio, it is used for all messages in the talk group. This system can instead use online/offline CP-ABE to create new talk groups. In this scheme, pieces of a ciphertext are created during offline periods where the radio is not actively transmitting or receiving messages. The pieces of ciphertext are created without knowing the plaintext to be encrypted or attributes used in the policy. Online/offline CP-ABE differs from regular CP-ABE in that all possible attributes are defined during the setup algorithm. This exchanges the flexibility of adding new attributes to an established system for faster CP-ABE encryption times. Because all possible attributes are known beforehand, a pool of ciphertext pieces corresponding to different attributes can be created. Assembling these pieces into a complete ciphertext is trivial and 99% of the work in encrypting the AES key using CP-ABE can be done offline [9]. For either system, CP-ABE encryption delay can be reintroduced if there are several short messages transmitted in a row. The radio may exhaust the stored keys and must generate a new one for the next message A System That Reuses AES Keys An alternate extension to the simple system is to reuse AES keys for multiple message transmissions. In this improvement, shown in Figure 1.6, the radio creating the group would 9

18 generate the CP-ABE ciphertext and AES key pair and transmit the CP-ABE ciphertext to all members of the group. After transmitting the AES encrypted message, the CP-ABE ciphertext and AES key are not discarded. Instead, the AES key is reused for all subsequent messages to that group. By reusing the AES key, the system effectively becomes a shared key system. If an adversary obtains the AES key, all messages are no longer secure. To address this problem, the AES key should be refreshed periodically. This can be done by requiring the first radio of the day to transmit on the talk group to generate a new AES key and CP-ABE ciphertext. All radios will then discard the previous CP-ABE ciphertext and AES key and use the new ones. Like the other two systems, the access policy needs to be encrypted and transmitted with each message. Because the AES key is reused, the access policy is not used to send encrypted replies on the new talk group. Instead, the access policy is used when the AES key and CP-ABE ciphertext are refreshed. To handle radios that match the access policy but are not monitoring the talk group when the first message is sent, the CP-ABE ciphertext should be sent with each message. This way the AES key can be recovered, and the new talk group added to the list of available talk groups. It is important that the AES setup parameters (initialization vector or nonce discussed in Chapter 2) should not be reused for the AES key. Doing so will leak information about the system to an attacker [10]. With this system the time taken for CP-ABE encryption and decryption is only performed when a message includes a new CP-ABE ciphertext. For subsequent messages, the delay will only be the time taken for AES encryption and decryption Key Management Key management is the method in which keys are distributed, revoked, and refreshed. There are many ways to distribute keys in a two-way radio system including at a service depot or in the field using a laptop. While the frequency of a key refresh should be determined based on the use case of the system, we recommend that the keys for CP-ABE be refreshed on a weekly or monthly basis. Having a shorter refresh period ensures that attributes are up to date for each radio and limits information leakage if keys are stolen. When refreshing or creating keys, a list of all 10

19 the attributes in the system should be compiled. This list is used to select attributes for new talk groups and should be distributed to each radio with the private key. Key revocation is another factor to address for using CP-ABE with two-way radios. In many encryption systems, a certificate is used to verify that a key is valid. Because CP-ABE does not use a certificate system, key revocation is used to confirm identity. We suggest the method described by Bethencourt, Sahai and Waters where an expiration date is added as a required attribute in the access policy. When the keys are refreshed, they will have a new expiration date attribute [3]. To make this a required attribute, it is included in the access policy using AND for every OR statement. In our CP-ABE example, a policy with an expiration date would be December 16 AND Police Chief OR December 16 AND Drug Enforcement AND Citytowne. This means both the Police Chief and Unit 0451 must have a key with the expiration date of December 16 to decrypt messages. Old keys will not decrypt current messages, even if all other attributes are correct. This means if Unit 0042 obtained a key with the attributes November 16, Unit 0451, Citytowne, only messages where the key is valid could be decrypted. Unit 0042 would not be able to decrypt the message. On other applications, such as the Internet of Things or file storage, using an expiration date is inefficient. The difference between these systems and a radio system is that radio messages are typically discarded after receipt. In file storage, keys must match the date the files were encrypted with which can lead to many keys being kept [3]. A key must be kept for each expiration period the user needs file access to. Because radios only need to decrypt real-time messages, only the current key is needed, so no additional keys are kept. CP-ABE performance is affected by the number of attributes, so using an expiration date as an attribute can increase encryption and decryption times [4]. 1.4 CP-ABE Performance on Radios CP-ABE has the potential to work with deployed radio hardware using one of the systems we described, which we will explore in Chapter 5. First, computational overhead of CP-ABE must be analyzed. CP-ABE performs complex calculations which grow linearly with the number of attributes [4]. Field radios are typically computationally constrained, so a large number of attributes can introduce a significant delay to the system. Because two-way radio communication is a time- 11

20 critical application, any delay is detrimental. If the delay introduced by encryption or decryption is significant, the benefit of using a two-way radio is diminished. This thesis investigates the feasibility of applying CP-ABE to talk groups by measuring performance of the required software on several embedded devices. Although there have been ABE benchmarks on embedded devices, there has not been one from a two-way radio perspective. Two-way radios are typically in operation for several years or even decades before replacement. Because of this long life cycle, the microprocessors in service will vary greatly. Instruction set architecture (ISA), the number of cores, core clock speed, and the presence of cryptographic hardware can influence the performance of CP-ABE operations. We expect that certain microprocessor features will affect the performance of ABE much more than others. To estimate the performance for this application, CP-ABE and AES benchmarks will be run on a variety of single-board computers (SBC). From the data, we will suggest a limit to the number of attributes that can be used on the device to keep a reasonable latency. We will also investigate features that influence the performance of CP-ABE the most Reasoning for Using Single Board Computers We use SBCs instead of real radios because they are easy to obtain and inexpensive. Commercial radios typically cost hundreds of dollars, which was considered cost prohibitive for this study. Even if they had been purchased, it would have been necessary to license spectrum and purchase accessories to create a full system, increasing the total price. An alternative would be to use consumer radios, but they lack the features necessary for using CP-ABE. By using an SBC, we have complete control over the device. SBCs running full Linux distributions can compile any software with source code. Processor variables such as clock speed or cryptographic hardware can be changed, allowing the impact of different features to be measured. Support is community driven. Solutions to most problems with popular SBCs can be found freely on internet forums. Commercial radios may have support for compiling software, but control over processor variables such as clock speed may be limited or require additional licensing. Questions about programming issues must be directed at the manufacturer or vendor. There may be a delay in response or additional fee associated with the support. 12

21 On the other hand, using SBCs prevents certain aspects of the proposed system from being tested. The RF latency overhead of transmitting CP-ABE ciphertexts and encrypted messages depends on the radio system architecture. Different features will affect this latency, and it is beyond the scope of this study to test all system variations. As in other studies of CP-ABE embedded performance, we assume this delay of transmitting to be minimal with sufficient transmission bandwidth [8]. Radio processor overhead is another aspect we cannot test with SBCs. This overhead not only varies between radio manufacturers, but between product lines as well. Radio software with good resource management can use encryption schemes with minimal slowdown, but it is impossible to account for all relevant qualities of code. Because SBCs run a full operating system, there is inevitably a certain amount of overhead. For this study, we assume that the overhead and resource management of an SBC is equivalent to that of a radio with a similar processor. We considered creating a mockup of the proposed systems using the SBCs and networking as a transmission medium, but we concluded that this would not produce meaningful data. The purpose of our study is to determine the feasibility of using CP-ABE on two-way radios. A proof-of-concept system would only demonstrate that the devices can encrypt, send, and decrypt messages. The more critical questions to address focus on the performance implications of using AES and CP-ABE in the system with a varying number of attributes. These questions are readily addressed by running benchmark programs on SBCs. The remainder of this thesis is as follows: in Chapter 2, key concepts and background will be presented. Chapter 3 describes the tests performed and the hardware used. Chapter 4 discusses the results of our studies. In Chapter 5, we make suggestions for deploying a CP-ABE radio system based on our results. Chapter 6 concludes the thesis and suggests future work. 13

22 CHAPTER 2. THEORIES AND CONCEPTS To better understand our CP-ABE application, we give an overview of important underlying principles, beginning with the architecture and function of radio systems in Section 2.1. Section 2.2 provides the essential background on attribute-based encryption. Section 2.3 summarizes information about AES (the Advanced Encryption Standard). The chapter concludes with Section 2.4, which summarizes related work. 2.1 Two-Way Radio Systems Two-way radio, also known as land mobile radio (LMR) [11], allows communication between geographically separated units. This communication usually takes the form of short voice transmissions known as messages. To send a message, a user first selects the group they wish to communicate with. This is done by selecting either a frequency channel or talk group. The user starts a push-to-talk (PTT) event, usually by holding a button on a microphone or the radio. This starts a message call, where the user s voice is transmitted to all radios on the talk group. The message concludes when the PTT event ends with release of the button [1]. In this section we give an overview of radio systems to better understand our application. In Section 2.1.1, we summarize the radio standards used both in the past and present. Section describes common radio system architectures Land Mobile Radio Standards Since the creation of LMR, there have been several transmission standards. In the United States, LMR started with the transmission of analog voice messages from a fixed AM base station to a mobile receiver. This progressed to using a two-way FM system, operating in the FCC assigned VHF and the UHF portion of the radio spectrum [11]. 14

23 There are two major radio standards in use today. The standard primarily used in the United States is called Project 25 (P25). It is defined by the Association of Public-Safety Communications Officials-International (APCO). P25 moves LMR from analog to digital communication and serves as the core for most public safety communications. P25 is used in the United States, Russia, Brazil, Australia, New Zealand, and Canada. The other major standard is called TETRA (Terrestrial Trunked Radio) and is used in over 110 countries [11]. Although LMR has existed for over 80 years, the technology continues to evolve. In 2012, FirstNet was established with the goal of creating a United States nationwide public broadband network. This will use a single architecture based on LTE (Long Term Evolution) offering highspeed digital transmission [11] Radio System Architecture LMR not only offers a choice in the RF communication standard used, but also in the system architecture. Three common ones are simplex, repeater, and trunked [1]. Simplex Systems The simplest form of a radio system is simplex mode a single-hop ad-hoc system. In this mode, as illustrated in Figure 2.1, radios communicate directly with all other radios on the same frequency. The coverage area, or range in which radios can communicate with each other, is limited by the transmission power of the radios [1]. Repeater Systems A repeater extends the coverage area of a radio system which is shown in Figure 2.2. Instead of radios communicating directly with each other, radios communicate through repeater sites. By transmitting and receiving on separate frequencies, the repeater relays messages to other radios in the area [1]. Multiple repeaters can be connected by using a landline or other method. This allows the radios in different coverage areas to talk together [12]. Trunked Systems Instead of using fixed channels for communication, trunking (as seen in Figure 2.3) allows for dynamic frequency allocation by coordinating repeaters and field radios. A trunked system is ideal for areas with congested spectrum, as idle channels are better utilized [12]. A virtual channel, known as a talk group, must be selected to send or receive a message [1] [12]. 15

24 Frequency 1 Frequency 1 Figure 2.1: Simplex operation of a two-way radio system. Radios transmit directly to all other radios using one frequency. The coverage area is limited to the transmission distance of the radios [1]. A talk group is typically classified by the messages it carries. After the user selects a talk group, the radio monitors the system control channel for commands related to that talk group [1]. When a user starts a call on a talk group, the central controller assigns a channel from a pool for each repeater site. This pool typically consists of 20 to 30 frequencies per repeater site. The controller, through the system control channel, instructs every radio that has selected the talk group to tune to the assigned channel. After this set up period, which on average takes 500 ms, a tone alerts the user that they may begin speaking. After the completion of the call, the assigned channel returns to the pool and radios resume monitoring the control channel [1]. 2.2 Attribute-Based Encryption In this section we give a background on ciphertext-policy attribute-based encryption. An understanding of the computation required by the scheme is important in understanding the performance study and results in this thesis. In Section 2.2.1, we discuss the origin of attribute-based 16

25 Repeater Figure 2.2: Repeater operation of a two-way radio system. By using different frequencies to receive and transmit, a repeater can extend the coverage area of a radio system. [1]. encryption (ABE). We describe popular ABE schemes in Section This section concludes with which provides ABE math fundamentals and summarizes the essential aspects of the CP-ABE scheme Origin of Attribute-Based Encryption In traditional Public-Key Encryption (PKE), there is added complexity when sharing encrypted data within a group. Normally, a public key is used to encrypt a message and a private key is used to decrypt. When a message is shared with multiple parties, it is encrypted separately for each public-private key pair. PKE systems become complicated with a large userbase because multiple encryptions are required. Attribute-Based Encryption reduces this complexity since encryption is done once using a common public key [4]. ABE was conceived by combining two encryption ideas: Identity-Based Encryption (IBE) and secret sharing. In IBE, the public key is something unique related to the recipient such as a network address, telephone number, or employee ID [4] [13]. Secret sharing presents a (k, n) threshold scheme where secret data D is broken into n pieces. If a user has k or more pieces, they 17

26 Dispatch Central System Controller Channel Pool Frequency 1 Frequency 2... Frequency N Site Controller Channel Pool Frequency 1 Frequency 2... Frequency N Site Controller... Channel Pool Frequency 1 Frequency 2... Frequency N Site Controller N-Channel Repeater N-Channel Repeater N-Channel Repeater Repeater Site 1 Repeater Site 2 Repeater Site M... Talk Group 1 Talk Group 2 Talk Group 3 Talk Group 2 Talk Group 4 Talk Group K Figure 2.3: Trunked operation of a two-way radio system. A trunked system has multiple repeaters with access to a frequency pool. When a call is made, a system controller coordinates with repeaters and radios the frequencies that should be used for transmit and receive. This system extends coverage area, gives priority to important calls, and conserves spectrum [1]. can recover the data D. If the user has k 1 or fewer pieces, D remains secret [4] [14]. By using identity as a basis to create a threshold scheme, ABE was created [4] ABE Schemes Threshold Policy Access Control The first proposed ABE system was a threshold access control system called Fuzzy-IBE. Each user key is associated with a polynomial, generated from a biometric scan. In these applications, errors are introduced in the scanning process, but if the user meets at least k features they can decrypt the ciphertext [4] [15]. Key-Policy Access Control Key-Policy Attribute-Based Encryption (KP-ABE) applied finegrain access control to Fuzzy-IBE. In KP-ABE, each user key is created using an access policy which describes the user. Ciphertexts are associated with a list of attributes. If the attribute list on the ciphertext satisfies the key s access policy, the plaintext can be recovered. Because the ac- 18

27 cess policy is embedded in the keys, data owners have limited control over who can decrypt the ciphertext [4]. If our example in Chapter 1 used KP-ABE, the access policies would have to be carefully selected when generating keys. Recall the scenario where the police chief wished to send the message about the bust to all drug enforcement units in Citytowne. Say the key access policy is of the form [Unit Number] OR [Department] OR [City]. If the chief encrypts using the attribute list Drug Enforcement, Citytowne, any unit in Citytowne or the drug enforcement department can decrypt the message. This means the traitorous Unit 0042 learns about the bust. If the access policy used to create the keys was of the form [Unit Number] OR [Department] AND [City], Unit 0042 would not learn about the bust, but this makes encryption more complicated in other scenarios. With this access policy, the chief would have to re-encrypt the message using an attribute list for each department ( Drug Enforcement, Citytowne, SVU, Citytowne, etc.). From these scenarios we see that owner control of the access policy means control over decryption. Ciphertext-Policy Access Control In Ciphertext-Policy Attribute-Based Encryption (CP-ABE), the access control structure is embedded within the ciphertext and user keys are associated with a list of attributes. This means that the data owner has greater control over who can decrypt data. This flexibility comes with a slight performance cost because an additional step must be taken to randomize the private keys, but CP-ABE remains one of the more popular schemes [4]. Suppose we use the attribute list form in Chapter 1 to create keys ( [Unit Number], [Department], [City] ). To encrypt a message for units in Citytowne, the chief would simply use an access policy of Citytowne ABE Fundamentals Bilinear Maps A challenge in creating an ABE system is generating keys efficiently. Bilinear maps are the basis of ABE and allow the secure creation of keys in polynomial time [4]. When defining bilinear maps, G and G T are cyclic groups with the same large prime order q. G 1 and G 2 are the source group and are normally elliptic curves defined over the finite field F q. G T is the target group and 19

28 is defined on the finite field. G 1 G 2 G T defines the bilinear map e. When G 1 = G 2, it is a symmetric bilinear map. [4]. Admissible bilinear maps, which are used in ABE schemes, meet the following requirements [4]: 1. Bilinearity (g a 1,gb 2 ) = e(g 1,g 2 ) ab where g 1 and g 2 are the generators of G 1 and G 2. a,b Z p 2. Computability For any pairs G 1 G 2, the bilinear map e is efficiently computable. 3. Non-degeneracy All pairs in the map G 1 G 2 are not sent to the identity in G T. e(g 1,g 2 ) 1. The secret and public key are computed using bilinear pairing which maps a pair of points from the source group to the target [4]. Access Trees Access trees (τ) are used for fine-grained policy control encryption schemes such as CP- ABE. These trees are prepared before system startup. Each non-leaf node represents a threshold value and a threshold gate. The threshold value, k x, is described by 0 < k x num x, where num x is the number of children for node x. When k x = num x, this creates an AND gate. When k x = 1, this creates an OR gate. Leaf nodes are described by a threshold value k x = 1 and an attribute. To determine if the access tree is satisfied, a threshold match function is used [4]. This function, called DecryptNode, traverses from root to each leaf recursively [3]. Three additional functions are defined for working with access trees. The function att(x) is defined when the node x is a leaf node and represents the attribute associated with it. To determine the parent of node x, the function parent(x) is used. Finally, index(x) returns a number denoting the index of x [3]. CP-ABE Scheme Let G 0 be a bilinear group of prime order p. Let g be a generator of G 0. To denote the bilinear map, let e : G 0 G 0 1 [3]. To determine the size of the bilinear source group, the security parameter κ is used. The Lagrange coefficient i,s is then defined for i Z p and S, a set 20

29 of elements in Z p : i,s(x) = j S, j i x j i j. The hash function H : {0,1} G is used as a random oracle in CP-ABE to link a unique integer with each element in Z p [4]. CP-ABE can be described by the following functions also found in [3]: Setup A bilinear mapping and random exponents are used to generate the public key and master key. A bilinear group G 0 of prime order p with generator g is selected. Two random exponents are chosen: α,β Z p. The public key (PK) and master key (MK) are published as: PK = G 0,g,h = g β, f = g 1/β,e(g,g) α MK = (β,g α ). In this case, f is only used for delegation which will be explained shortly. Encrypt Using the specified access tree (τ) and the public key, a ciphertext (CT) is created from a message (M). A polynomial q x is selected for each x, each node and leaf in τ. Starting from root node R, the polynomials are chosen top-down. For each x, set the degree (d x ) of the polynomial q x to be one less than the threshold value (k x ) of that node: d x = k x 1. Starting at R, a random s Z p is chosen and q R (0) = s is set. In the polynomial q R, d R other points are chosen randomly. This completely defines q R. q x (0) = q parent(x) (index(x)) is set for any other node x; d x other points are randomly chosen to fully define q x. Y is a set of leaf nodes in τ. The ciphertext is created by: CT = (τ, C = Me(g,g) αs,c = h s, y Y : C y = g q y(0),c y = H(att(y)) q y(0)) ). Key Generation Generates a user s secret key (SK) by taking in a set of attributes (S) and the master key. A random r Z p is chosen, followed by a random r j Z p selected for each attribute j S: SK = (D = g (α+r)/β, j S : D j = g r H( j) r j,d j = g r j ), where SK is the secret key. Delegate (Optional) Creates a new secret key using a user s secret key and a subset of the attributes used to create it ( S). The desired attributes S are a subset of S, S S. The form of SK is 21

30 (D, j S : D j,d j ). A random r and r k k S are chosen: SK = ( D = D f r, k S : D k = D k g r H(k) r k, D k = D k g r k ), where SK is the new secret key. Decrypt Using the ciphertext and a user s secret key, the plaintext is decrypted. This only occurs if the attributes of the user s secret key satisfy the access tree used during the encryption process. This relies on a function called DecryptNode, taking as input: the ciphertext (in the form CT = (τ, C,C, y Y : C y,c y)), a secret key associated with a set of attributes S, and node x in the access tree. When x is a leaf node, i = att(x). If i S: DecryptNode = e(d i,c x ) e(d i,c x) = e(gr H(i) r i,h q x(0) ) e(g r i,h(i) q x(0) ) = e(g,g) rq x(0). If i / S, DecryptNode results in. If x is a non-leaf node, it represents an AND or an OR gate in the tree and DecryptNode recursively calls itself for all nodes z that are children of x. The output of this call is stored as F z. S x is a k x -sized set of z where F z. If S x does not exist, DecryptNode returns. If the set exists, compute the result: F x = F i,s x (0) z S x z, where = (e(g,g) r qx(0) ) i,s (0) x z S x i=index(z) S x={index(z):z S x } = (e(g,g) r qparent(z)(index(z)) ) i,s (0) x z S x = e(g,g) r q x(i) i,s (0) x z S x = e(g,g) r q x(0) (by construction) (using polynomial interpolation). 22

31 Using DecryptNode, the decryption algorithm of CP-ABE can be defined. First DecryptNode is run on the root node R of τ. If S satisfies τ: A = DecryptNode(CT,SK,r) = e(g,g) rq R (0) = e(g,g) rs. The plaintext (M) is recovered by: C/(e(C,D)/A) = C/(e(h s,g (α+r)/β )/e(g,g) rs ) = M. Security Bilinear maps are the basis for ABE schemes. The security for bilinear maps is found in the Computational Diffie-Hellman assumption (CDH): For any randomly chosen generator g and cyclic group G with order q given tuple {(g,g a,g b ) a,b Z p }, compute g ab. Computing g ab is intractable because it involves computing the discrete logarithm of a base value generator g, which is a hard problem [4]. Threshold Policy ABE, KP-ABE, and CP-ABE have all been shown to be secure under an extension of CDH called the Decisional Bilinear Diffie-Hellman assumption (DBDH): Distinguish the two tuples {(g a,g b,g c,e(g,g) abc a,b,c Z} and {(g a,g b,g c,e(g,g) z a,b,c,z Z}. The ABE schemes are secure because there is no polynomial-time algorithm to distinguish the two tuples [4]. 2.3 Advanced Encryption Standard In our scheme, we use CP-ABE to encrypt an Advanced Encryption Standard (AES) key. AES is then used for message encryption. In this section we provide a historical background on AES (Section 2.3.1) along with a synopsis of how it functions (Section 2.3.2), followed by a discussion of common AES block cipher modes (Section 2.3.3). As with CP-ABE, an understanding of the complexity and operations required is important in understanding our results and analysis. 23

32 2.3.1 History of AES For many years, the Data Encryption Standard (DES) was a widely used block cipher for encryption. As technology improved, problems with DES began to appear. The small key size of DES had poor security as computer processor power increased and performance suffered as average file size became larger. An improvement of the scheme, known as 3DES, ran the encryption algorithm on blocks three times in a row. This temporarily solved the security issue of a small key size at the cost of tripling the encryption time [10]. The National Institute of Standards and Technology, a part of the United States government, consulted the cryptographic community for a DES replacement. Out of 15 submissions and 5 finalists, the Rijndael cipher was selected to become the Advanced Encryption Standard (AES) [10] AES Implementation AES, formerly called Rijndael, is a block cipher operating on 16 bytes at a time. Its operation is illustrated in Figure 2.4 and consists of a repeated series of functions called a round. A round is repeated several times determined by the size of the encryption key. The number of rounds is denoted as N r : 10 rounds for a 128-bit key, 12 rounds for a 192-bit key, and 14 rounds for a 256-bit key [16]. N r increases for larger keys primarily to protect against shortcut attacks attacks which are more efficient than an exhaustive key search. This category of attacks is more effective against larger key sizes. For this reason, N r is increased by 1 for every additional 32 bits in a key to reduce shortcut attack effectiveness [17]. At the beginning of the scheme, the cipher key is expanded to create N r + 1 round keys. These round keys will be used each round in the Add Round Key function described below. Before performing the rounds, an initial Add Round Key function is performed [16]. Each round consists of the following steps: Byte Substitution Each byte in the block is replaced with a value from a pre-defined substitution table (also known as an S-box). The substitution value is determined by using the two nibbles in the byte to index into the S-box. This substitution is demonstrated in Figure 2.5 [16]. 24

33 Key Expansion Add Round Key Byte Substitution Shift Rows Mix Columns Rounds Repeat: 9 times for 128-bit keys 11 times for 192-bit keys 13 times for 256-bit keys Add Round Key Byte Substitution Shift Rows Final Round Add Round Key Figure 2.4: AES scheme outline. After an initial key expansion, a series of functions called a round are performed on the block. These rounds are repeated depending on the size of the encryption key. The final round does not perform the Mix Columns function [16]. Shift Rows The block is arranged in rows and columns. Rows are cyclically shifted a number of bytes as seen in Figure 2.6. Row 0 is not shifted, row 1 is shifted by one byte, row 2 by two bytes, and row 3 by three bytes [16]. 25

34 a 0,0 a 0,1 a 0,2 a 0,3 S-box b 0,0 b 0,1 b 0,2 b 0,3 a 1,0 a 1,1 a 1,2 j,k a 1,3 b 1,0 b 1,1 b 1,2 j,k b 1,3 a 2,0 a 2,1 a 2,2 a 2,3 b 2,0 b 2,1 b 2,2 b 2,3 a 3,0 a 3,1 a 3,2 a 3,3 b 3,0 b 3,1 b 3,2 b 3,3 Figure 2.5: AES byte substitution. For each byte of the block, the two nibbles are used as an index to look up a substitution value in a pre-defined substitution table or S-box [17]. a 0,0 a 0,1 a 0,2 a 0,3 No Shift a 0,0 a 0,1 a 0,2 a 0,3 a 1,0 a 1,1 a 1,2 a 1,3 Cyclic Shift by 1 a 1,1 a 1,2 a 1,3 a 1,0 a 2,0 a 2,1 a 2,2 a 2,3 Cyclic Shift by 2 a 2,2 a 2,3 a 2,0 a 2,1 a 3,0 a 3,1 a 3,2 a 3,3 Cyclic Shift by 3 a 3,3 a 3,0 a 3,1 a 3,2 Figure 2.6: AES shift rows. The block is arranged into rows and columns. Rows are cyclically shifted by a number of bytes [17]. Mix Columns The block is arranged in rows and columns. As illustrated in Figure 2.7, each byte in a column is treated as a coefficient for a polynomial and is multiplied by a specific function. This function is not performed on the final round [16]. Add Round Key A round key (generated at the outset during key expansion) is added by performing a bitwise XOR with the block. This is illustrated in Figure 2.8. This function is also performed after key expansion [16]. 26

35 a 0,j a 0,0 a 0,1 a 0,2 a 0,3 c(x) b 0,j b 0,0 b 0,1 b 0,2 b 0,3 a 1,0 a 1,1 a 1,2 1,j a 1,3 b 1,0 b 1,1 b 1,2 1,j b 1,3 a 2,0 a 2,1 a 2,2 2,j a 2,3 b 2,0 b 2,1 b 2,2 2,j b 2,3 a 3,0 a 3,1 a 3,2 a 3,3 b 3,0 b 3,1 b 3,2 b 3,3 a 3,j b 3,j Figure 2.7: AES mix columns. The block is arranged into rows and columns. Each column is treated as a polynomial, using each byte in the column as a coefficient. The created polynomial is then multiplied by a specific function [17]. a 0,0 a 0,1 a 0,2 a 0,3 k 0,0 k 0,1 k 0,2 k 0,3 b 0,0 b 0,1 b 0,2 b 0,3 a 1,0 a 1,1 a 1,2 a 1,3 k 1,0 k 1,1 k 1,2 k 1,3 = b 1,0 b 1,1 b 1,2 b 1,3 a 2,0 a 2,1 a 2,2 a 2,3 k 2,0 k 2,1 k 2,2 k 2,3 b 2,0 b 2,1 b 2,2 b 2,3 a 3,0 a 3,1 a 3,2 a 3,3 k 3,0 k 3,1 k 3,2 k 3,3 b 3,0 b 3,1 b 3,2 b 3,3 Figure 2.8: AES add round key. A round key (the array of 16 k bytes depicted above) is added by performing a bitwise XOR with the block [17]. The round functions of AES can be performed to some degree in parallel [10]. Some examples of exploitable parallelism include: multiple queries to the S-Box in byte substitution, performing multiple operations at once in shift rows and mix columns, and XOR operations in add round key. This parallelism makes it very fast on hardware that can take advantage of it [17]. Decryption requires a different S-box and mixing scheme, however, so resource use is more than other schemes. This can be avoided by using stream ciphers discussed later in the chapter [10]. 27

36 AES was aggressively designed for security and this is the reason multiple rounds are performed. No practical attacks exist at the rounds described in the specification. Block ciphers, however, are vulnerable to birthday attacks and meet-in-the-middle attacks (these are well known attacks described in cryptology literature). For this reason, experts in the field of cryptography suggest using 256-bit keys (as opposed to 192-bit or 128-bit keys) as an added margin of protection when using block ciphers such as AES [10] Block Cipher Modes Since most messages are longer than the block size of 16 bytes, a block cipher mode is used to encrypt larger data sizes. We describe several of the popular modes along with benefits and potential security hazards [10]. Electronic Code Book Mode Electronic Codebook (ECB), depicted in Figure 2.9, is the simplest mode for encrypting multiple blocks. ECB simply performs encryption on each block of the plaintext: C i = E(K,P i ) f or i = 1,...,n, where n is the total number of blocks, i is the current block, P i is the plaintext block i, K is the encryption key, E is the ECB encryption function, and C i is the ciphertext of P i. Because ECB operates on individual blocks, some parallelism can be exploited by encrypting multiple blocks at the same time which results in a speed increase. Unfortunately, this mode can leak information about the plaintext. For example, if two blocks are the same, they will appear identical when encrypted. Because of this, ECB is considered a weak mode [10]. 28

37 Plaintext 1 (P 1 ) Plaintext 2 (P 2 ) Plaintext n (P n ) Key (K) Block Cipher Encryption Key (K) Block Cipher Encryption... Key (K) Block Cipher Encryption Ciphertext 1 (C 1 ) Ciphertext 2 (C 2 ) Ciphertext n (C n ) Encryption Ciphertext 1 (C 1 ) Ciphertext 2 (C 2 ) Ciphertext n (C n ) Key (K) Block Cipher Decryption Key (K) Block Cipher Decryption... Key (K) Block Cipher Decryption Plaintext 1 (P 1 ) Plaintext 2 (P 2 ) Plaintext n (P n ) Decryption Figure 2.9: Electronic codebook mode [18]. Each block of data is encrypted independently using the encryption block cipher. To decrypt, the decryption block cipher is used [10]. Cipher Block Chaining Mode Cipher Block Chaining (CBC), described pictorially in Figure 2.10, XORs the current plaintext block (P i ) with the previous ciphertext block (C i 1 ): C 0 = Initialization Vector C i = E(K, P i C i 1 ) f or i = 1,...,n, 29

38 Initialization Vector (C 0 ) Plaintext 1 (P 1 ) Plaintext 2 (P 2 ) Plaintext n (P n ) Key (K) Block Cipher Encryption Key (K) Block Cipher Encryption Key (K) Block Cipher Encryption Ciphertext 1 (C 1 ) Ciphertext 2 (C 2 ) Ciphertext n (C n ) Encryption Ciphertext 1 (C 1 ) Ciphertext 2 (C 2 ) Ciphertext n (C n ) Key (K) Block Cipher Decryption Key (K) Block Cipher Decryption Key (K) Block Cipher Decryption Initialization Vector (C 0 ) Plaintext 1 (P 1 ) Plaintext 2 (P 2 ) Plaintext n (P n ) Decryption Figure 2.10: Cipher block chaining mode [18]. For encryption, each block of the plaintext is XORed with the previous ciphertext before using the encryption block cipher. An initialization vector is used for the first block. For decryption, the decryption block cipher is used and then XORed with the previous ciphertext [10]. where n is the total number of blocks, i is the current block, K is the encryption key, E is the CBC encryption function, and C i is the ciphertext of P i. For C 0, a number called the initialization vector (IV) should be used. While any number can be used for an IV, using a random number will reduce information about a plaintext to an attacker. To pass an IV to the decrypting party, it is encrypted using the key and sent as the first block. This increases the size of the ciphertext by one block [10]. 30

39 Initialization Vector (K 0 ) Key (K) Block Cipher Encryption Key (K) Block Cipher Encryption Key (K) Block Cipher Encryption Key Stream 1 (K 1 ) Key Stream 2 (K 2 ) Key Stream n (K n ) Plaintext 1 (P 1 ) Ciphertext 1 (C 1 ) Plaintext 2 (P 2 ) Ciphertext 2 (C 2 ) Plaintext n (P n ) Ciphertext n (C n ) Encryption Initialization Vector (K 0 ) Key (K) Block Cipher Encryption Key (K) Block Cipher Encryption Key (K) Block Cipher Encryption Key Stream 1 (K 1 ) Key Stream 2 (K 2 ) Key Stream n (K n ) Ciphertext 1 (C 1 ) Plaintext 1 (P 1 ) Ciphertext 2 (C 2 ) Plaintext 2 (P 2 ) Ciphertext n (C n ) Plaintext n (P n ) Decryption Figure 2.11: Output feedback mode [18]. This is a stream cipher, meaning that the block cipher is used to create a key stream a pseudorandom stream of bytes. To encrypt or decrypt, the block is XORed with the key stream. The encryption block cipher is used for both encryption and decryption. An initialization vector is used to start the key stream [10]. Parallelism is limited with CBC, because encryption or decryption relies on the result of the previous block [18]. 31

40 Output Feedback Mode Output feedback mode (OFB) is a type of stream cipher as shown in Figure Instead of transforming the plaintext by using the block cipher, the block cipher is used to generate a key stream (a pseudorandom stream of bytes). The key stream (K i ) is then XORed with the block plaintext (P i ) to create the ciphertext (C i ). In OFB, a new key stream is generated by using the block cipher on the previous key stream (K i 1 ): K 0 = IV K i = E(K,K i 1 ) f or i = 1,...,n C i = P i K i, where n is the total number of blocks, i is the current block, K is the encryption key, and E is the OFB encryption function. For K 0, an initialization vector is used to start the key stream, like CBC. It is very important that the IV is unique when used in OFB. If an IV is reused, the same key stream is generated. If the attacker knows a previous plaintext and ciphertext used with the IV, the new plaintext can be recovered [10]. Like CBC, OFB also relies on the previous block result for encryption and decryption. This limits the amount of parallelism that can be exploited [18]. However, stream ciphers require fewer resources than other block cipher modes. Because the block cipher is used indirectly, the same cipher is used for both encryption and decryption. Padding, the processes of adding data to increase short blocks to 128-bits, is also unnecessary [10]. Counter Mode Counter mode (CTR) is another stream cipher, illustrated in Figure The counter (i) is concatenated with a unique number, called a nonce, and then encrypted to generate the key stream (K i ). This key stream is then XORed with the plaintext block (P i ): 32

41 Counter 1 (Nonce 1) Counter 2 (Nonce 2) Counter n (Nonce n) Key (K) Block Cipher Encryption Key (K) Block Cipher Encryption... Key (K) Block Cipher Encryption Key Stream 1 (K 1 ) Key Stream 2 (K 2 ) Key Stream n (K n ) Plaintext 1 (P 1 ) Ciphertext 1 (C 1 ) Plaintext 2 (P 2 ) Ciphertext 2 (C 2 ) Plaintext n (P n ) Ciphertext n (C n ) Encryption Counter 1 (Nonce 1) Counter 2 (Nonce 2) Counter n (Nonce n) Key (K) Block Cipher Encryption Key (K) Block Cipher Encryption... Key (K) Block Cipher Encryption Key Stream 1 (K 1 ) Key Stream 2 (K 2 ) Key Stream n (K n ) Ciphertext 1 (C 1 ) Plaintext 1 (P 1 ) Ciphertext 2 (C 2 ) Plaintext 2 (P 2 ) Ciphertext n (C n ) Plaintext n (P n ) Decryption Figure 2.12: Counter mode [18]. Counter mode is a stream cipher. A counter is used to create the key stream which is then XORed with the block [10]. K i = E(K, Nonce i) f or i = 1,...,n C i = P i K i, where n is the total number of blocks, K is the encryption key, E is the CTR encryption function, and C i is the ciphertext of P i. 33

42 A nonce does not have to be secret but should only be used once per message or file with a given key to prevent plaintext leakage. A system may choose to add additional data as a seed for the key stream. For the 128-bit block size of AES, cryptography experts suggest using 48-bits for the message number, 16 bits for nonce data, and 64-bits for the counter. With this type of seed, 2 48 messages can be used with a maximum of 2 68 bytes per message [10]. Because each block is operated on separately, multiple blocks can be encrypted or decrypted in parallel [18]. Security and Recommended Modes The two modes recommended by the experts Ferguson, Schneier, and Kohno are CTR and CBC. These modes do not display the weaknesses of OFB or ECB. ECB encrypts all blocks in the same identical way. If two identical blocks are encrypted, the output will be the same. This can give an attacker insight into what a message contains. The other ciphers can leak information if an IV or nonce is repeated, but with CTR and CBC it is less catastrophic. Ferguson, Schneier, and Kohno stress that selection of a random IV and using a nonce just once per key are essential for security. When designing a new system, it is suggested that CBC with a random IV be used as it can be difficult to ensure a unique nonce when using CTR [10]. 2.4 Related Work CP-ABE Applications The Internet of Things (IoT) consists of devices that monitor, receive, and communicate information related to their environment. Members will join and leave a system dynamically, so context is important when sharing information [19]. Applying ABE to IoT is an important research topic, as data can be shared or kept secret based on the attributes of the requesting party. Health care devices and vehicular networks can use ABE to selectively share information [20] [21]. Data types are encrypted so only groups that need specific information are granted access. A medical wearable might provide doctors with a patient s heart rate information for the past month, but only the current heart rate for nurses [20]. The data available to a service technician 34

43 from a vehicle network would differ from data available to a police officer or insurance agent [21]. Data sharing works for collaborating IoT devices as well, where CP-ABE is used to selectively share information based on a device s attributes [22]. Another data-sharing application for two-way radio is described by Liu et al. Cognitive Radio Networks (CRN) allow spectrum sharing between licensed and unlicensed users. In a CRN, a database contains information about radio installations such as antenna height, transmission power, and times of operation. This database is queried by users to reduce interference between networks. In some instances, it is desirable to keep this information private for certain parties, such as transmitter specifications of military or government facilities. Applying ABE to the database allows control over the information released, keeping it secret from those who do not have the correct attributes [23]. Tokens broadcast via wireless beacons can determine which individuals are within the general area. ABE is used to encrypt the token with attributes describing users with access to the location. If the attributes are met the token can be used to log into computers with a simplified sign-on [24] or authorize the use of firearms [25]. While using ABE in the Internet of Things is an exciting prospect, there are some hurdles to overcome before practical use. A primary issue is that IoT devices have limited computing power and the cost to use ABE is high CP-ABE Performance CP-ABE is more complex than other forms of ABE. It uses a two-level masking methodology, a hash function, and the tree structures are complex [4]. In their paper presenting CP-ABE, Bethencourt et al. proposed some improvements for better performance. By ending traversal when the tree is satisfied, combining leaves of the same attribute, and computing nodes directly in a flattened tree, decryption times are lower [3]. Encryption and decryption time is linear, scaling with the number of attributes. Some features of CP-ABE can dramatically increase the attribute count, causing a significant performance degradation. Adding a NOT modifier doubles the number of attributes because access trees are monotonic [3] [4]. Support for numerical comparisons also increases the count using a bag of bits [26]. This method expands trees to compare each individual bit in a numerical attribute [3]. 35

44 With the many applications in IoT, an active topic of research is in analyzing and improving performance on constrained devices. By using the estimated time needed to perform exponentiations, an early study concluded that CP-ABE encryption performance on an embedded device is acceptable. These estimates showed that while performance on a PC was relatively quick, it would take several seconds to perform the same function on a PDA [20]. This is confirmed by benchmarks that show the practical maximum for IoT devices is around 10 attributes [27] [8]. 36

45 CHAPTER 3. METHODS AND IMPLEMENTATION To estimate the performance of a CP-ABE system on a radio using an embedded microprocessor, we execute benchmarks on several single-board computers (SBC). This chapter describes the devices and benchmarks used. In Section 3.1, we present the tested SBCs. Section 3.2 describes the CP-ABE benchmark. Section 3.3 describes the AES benchmark. These sections also lay out our goals and the results we expect to see from the experiment. A summary of our test plan is provided in Section 3.4 and Table Tested Devices To represent the multitude of processors that may exist on two-way radios, SBCs primarily from the Raspberry Pi family are selected. Running ARM processors from Broadcom, these SBCs cover a variety of embedded processor architectures, clock speeds, and cores. All tested Raspberry Pi boards are running a Raspbian Stretch Lite operating system, with a 4.9 Linux kernel. The Raspberry Pi 1B and the Raspberry Pi 0W run the same single-core processor, but form factor, clock speed, and peripherals are different [32]. Because the same processor is used, the effect of clock speed on cryptographic performance can be compared [32]. The Raspberry Pi 2B and Raspberry Pi 3B run quad-core processors with relatively recent architectures. With these, data concerning multi-threading and architecture improvements can be collected. A BeagleBoard BeagleBone Black featuring a Sitara ARM processor from Texas Instruments was also selected for testing. It runs the same ISA as the Raspberry Pi 2B, but only with one core. The clock speed is also different (1GHz) compared to the Raspberry Pi 2B s quadcore (900MHz). The main reason for testing a BeagleBone Black is that the processor features a cryptographic core, which allows comparisons between hardware and software encryption perfor- 37

46 Table 3.1: Single board computer specifications [28] [29] [30] [31] [32] [33] [34] mance [28] [30]. The BeagleBone Black is running a Debian Jessie operating system with a 4.4 Linux kernel. By performing benchmarks on these five SBCs, summarized in Table 3.1, our goal is to estimate how CP-ABE and AES would perform on two-way radios. Ultimately, we would like to determine the extent to which computers with these computational capabilities can support real time communication with a varying number of attributes. By comparing results, we show how clock speed, architecture, multi-threading, and cryptographic hardware affect the speed of a CP- ABE system. 3.2 CP-ABE Benchmark This section is about the CP-ABE benchmark. In Section we discuss the selected CP-ABE implementation to serve as basis for the benchmark. Section describes our modifications to the implementation to create the benchmark. Section describes our reasoning and methodology for selecting CP-ABE attributes for the benchmark. We state the expected outcomes for the CP-ABE benchmark in Section CP-ABE Implementations After looking at various implementations of the CP-ABE scheme, we selected the cpabe toolkit for our benchmark. The cpabe toolkit is a proof of concept program suite created by Bethencourt et al. which includes programs for running a CP-ABE system [6]. We chose the 38

47 cpabe toolkit over others because it is commonly used for research [4] and reportedly has fewer bugs. The toolkit uses two libraries: PBC and libbswabe. The PBC library provides pairingbased cryptography functions and is used for algebraic operations [35]. The libbswabe library was written by Bethencourt et al. and contains cryptography functions required by the CP-ABE scheme [6] Modifications to the cpabe Toolkit We modified the encryption program of the cpabe toolkit to be our benchmark program. The goal of the benchmark program is to time CP-ABE encryption and decryption for the attributes passed in. After parsing the arguments and the access tree, the generation of the AES key and CP-ABE ciphertext is timed. Immediately after, the decryption of the ciphertext is timed. If the encryption and decryption are successful, the timing information and number of attributes are output as comma separated values. If encryption or decryption is unsuccessful or if the decrypted key does not match the plaintext key, an error statement is printed. This benchmark program only times the encryption and decryption of CP-ABE. Setup and key generation are typically performed on an unconstrained device [36], so we do not test this performance on the SBCs. AES, which is used for the bulk of encryption, is tested using a separate benchmark which will be discussed in Section Attributes for the Benchmark In previous studies, it was argued that most smart devices will not use more than 30 attributes [8] [27]. We believe this applies to CP-ABE two-way radios, so our benchmark is run using from 1 to 30 attributes. Because decryption speed is related to the number of attributes matched, the benchmark access policy uses AND modifiers for encryption and decryption. This ensures that all attributes in the policy are matched. 39

48 We created a total of 30 private keys, each having 1 to 30 attributes. These are then used to decrypt the ciphertexts, matching the number of attributes in the key to the number of attributes in the benchmark run Expected Outcomes We expect higher clock speeds and newer processor architectures to show the greatest performance for CP-ABE. We expect marginal improvement on devices with multiple cores because the cpabe toolkit does not have code to take advantage of them. Overall, we seek to determine the number of attributes in CP-ABE where performance on the selected device is acceptable. As maximum acceptable delays, we choose 1 second for encryption and 1 second for decryption when using CP-ABE in a radio application. 3.3 OpenSSL AES Benchmark OpenSSL is an encryption program with a cryptographic library for use in software development. The encryption program has a benchmark mode for several encryption schemes, with options to use multi-threading and/or using cryptographic hardware. We chose OpenSSL to benchmark AES rather than writing our own program because of the maturity of the project and wealth of features. In Section 3.3.1, we provide the settings used for the AES benchmark. Section is about benchmarks to determine what affect specific hardware features have on AES performance. Section discusses acceptable AES performance AES Benchmark Settings We run AES in CTR and CBC modes as these are the modes recommended by experts [10]. Encryption benchmarks are run in software mode for each SoC using 128, 192, and 256-bit keys. It is assumed that encryption performance is indicative of decryption performance, as the differences between the two are a different S-Box and order of operation [10]. GNU Time is used to monitor processor load for each benchmark run for comparison between software and hardware. An example of the OpenSSL benchmark output is shown in Figure 3.1. The benchmark records the number of blocks encrypted over the course of three seconds. This is repeated for data 40

49 >openssl speed -elapsed -evp aes-256-ctr You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-ctr for 3s on 16 size blocks: aes-256-ctr's in 3.00s Doing aes-256-ctr for 3s on 64 size blocks: aes-256-ctr's in 3.00s Doing aes-256-ctr for 3s on 256 size blocks: aes-256-ctr's in 3.00s Doing aes-256-ctr for 3s on 1024 size blocks: aes-256-ctr's in 3.00s Doing aes-256-ctr for 3s on 8192 size blocks: aes-256-ctr's in 3.00s Doing aes-256-ctr for 3s on size blocks: 5679 aes-256-ctr's in 3.00s OpenSSL 1.1.0f 25 May 2017 built on: reproducible build, date unspecified options:bn(64,32) rc4(char) des(long) aes(partial) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS - DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m - DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM - DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/arm-linux-gnueabihf/ engines-1.1\"" The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes bytes aes-256-ctr k k k k k k Figure 3.1: AES benchmark output example. Results are displayed as thousands of bytes per second processed for each data size. sizes of 16, 64, 256, 1024, 8192, and bytes. The number of bytes processed for each block size is printed at the end of the benchmark [37]. The settings used for the benchmark are based on those found in the Texas Instruments Wiki page for AM335x Crypto Performance [38]. This includes recording processor load using GNU Time and running the benchmark in elapsed time. Running in elapsed mode gives more accurate results, and for consistency all benchmarks are run with the flag. We recognize that running in elapsed time will record other forms of overhead, but this is more representative of performance in a real system. The flag to use envelope (EVP) ciphers, which provides support for external cryptographic engines, was also enabled [37] [38]. This flag only affects the hardware test of the BeagleBone but was enabled for all tests for consistency Hardware Specific Benchmarks We also run additional OpenSSL AES benchmarks which take advantage of specific microprocessor features. The BeagleBone Black features a hardware accelerator for AES. We run an additional OpenSSL benchmark to see how this hardware affects AES performance. OpenSSL 41

50 and a driver kernel module must be compiled for cryptographic core support. We chose to use the Cryptodev-linux module, following compilation and use steps found online [38] [39]. On SBCs that feature multiple cores (Raspberry Pi 2B and 3B), we run the OpenSSL AES benchmark with multiple threads. This will determine if there is any performance advantage to having multiple cores Acceptable AES Performance for Audio Audio on two-way radios must be of sufficient quality to support speech comprehension, but this does not necessarily require high bit rates or a high sampling rate. Because our audio will be encrypted using AES, the decryption throughput will need to be enough to ensure playback is not waiting for decryption of the next block. If throughput is too low, gaps will be heard in the audio playback. We choose the minimum performance to be 16,000 bytes per second. This number is based on audio files found in the Open Speech Repository [40]. These files are a series of Harvard phonetically balanced sentences that are used for voice quality tests and recorded at a 16-bit depth and a 8KHz sample rate (16,000 bytes per second). While audio recorded in this format is not high fidelity, it is suitable for speech. We examine results at 16 bytes and 16 kilobyte data sizes, which represents an absolute worst case and a realistic worst case respectively. We consider 16 bytes the absolute worst case because it is the block size for AES. Any data encrypted with AES that is smaller than the block size will be padded until it is 16 bytes. The lowest overall throughput should be at 16 bytes because each block has CTR or CBC overhead associated with it. The 16 kilobyte data size will be more representative of a realistic worst case, because a user cannot press and release a PTT button quickly enough to produce a 16 byte message. Short messages, such as yes or no, are expected to be common. As 16 kilobytes is roughly the size of a 1 second message, it is a good representative of these types of short messages. Because AES was designed to be fast [10], we expect it to perform acceptably on all tested hardware. We expect the difference between CBC mode and CTR mode to be negligible. As with the CP-ABE benchmark, we will compare the performance contributed by different processor vari- 42

51 Table 3.2: Test plan summary ables. While newer architectures and clock speeds will affect AES speed, we expect performance using multi-threaded and cryptographic hardware to be significantly better. 3.4 Test Plan Summary We run the modified cpabe toolkit on each SBC to determine CP-ABE encryption and decryption performance with 1 through 30 attributes using the AND operator. We generate 30 private keys with attributes to match the decryption access policies. Each attribute level is performed 10 times and we report mean performance. We run the OpenSSL benchmark on each device in elapsed time with EVP AES ciphers. For 128, 192, and 256-bit keys, CBC and CTR block cipher modes are run. GNU time is run to determine the processor load during the benchmark to verify that the processor is being fully utilized during software tests. All devices are tested in single-threaded software mode. 43

52 We run additional tests for select SBCs to explore their unique hardware capabilities. To exercise the multiple cores on the Raspberry Pi 2B and Raspberry Pi 3B, we run with four threads. The cryptographic hardware module on the BeagleBone Black is benchmarked. We also use GNU Time to determine the effect of a cryptographic module on processor load. For CP-ABE, our goal is to determine the maximum number of attributes that can be encrypted or decrypted in under 1 second (our stipulated maximal delay) for the selected SBCs. We also measure AES throughput to ensure that it exceeds our minimum of 16,000 bytes per second. For CP-ABE and AES, we compare the performance contribution of clock speed, multi-core, architecture, and cryptographic hardware. 44

53 CHAPTER 4. RESULTS AND ANALYSIS This chapter presents the results of our AES and CP-ABE benchmarks. Section 4.1 goes over the CP-ABE benchmark results and highlights interesting or unexpected results. In Section 4.2, we discuss the results of the AES benchmark. 4.1 CP-ABE Performance Figures 4.1 and 4.2 show average encryption and decryption times versus the number of attributes across all SBCs. As can be seen, the overhead increases linearly with the number of attributes. Decryption is also faster than encryption, most likely due to improvements implemented in the software (see Section 2.4.2). This agrees with previously published results from CP-ABE benchmarks. As expected, the benchmark runs best on newer hardware (see Table 4.1 for architecture release year), but interesting results are seen when we compare the hardware features at the 30 attribute maximum. In Section 4.1.1, we compare the CP-ABE benchmark results of the Raspberry Pi 1B and 0W. Section deals with results on SBCs with multiple cores. The benchmark results of devices running at 1GHz is reported in Section We discuss processor features that most influence the performance of the CP-ABE benchmarks and the meaning of the overall result in Section Raspberry Pi 1B and Clock Speed In Figures 4.1 and 4.2, the largest difference at 30 attributes is seen between the Raspberry Pi 1B and Raspberry Pi 0W is 1.41 seconds for both encryption and 0.93 seconds for decryption. As stated previously in Section 3.1, these boards share the exact same processor only clocked at different speeds. We can safely assume that the better performance of the Raspberry Pi 0W is due to higher processor clock. 45

54 Figure 4.1: Average CP-ABE encryption time vs. number of attributes. Performance appears to be mostly along the lines of processor architecture release date. The Raspberry Pi 3B s Cortex-A53 (released in 2014) performs encryption at 30 attributes the fastest. The 1176JFZ-S used on the Raspberry Pi 1B and 0W had the slowest encryption time. The processor architecture is also the oldest (released in 2004). The multiple cores of the Raspberry Pi 2B do not significantly increase encryption speed over the BeagleBone Black, which shares the same instruction set architecture (ARMv7-A). The Raspberry Pi 0W and 1B share the same processor, but the 0W is clocked higher which accounts for the faster encryption time over the 1B Effect of Multiple Cores The Raspberry Pi 2B has more cores than the BeagleBone Black, but CP-ABE performance is about the same on both boards. Although the benchmark was not written to take advantage of multiple threads, we had expected that compiler optimization would do so to some degree. This does not seem to be the case with the lower performance most likely being due to the lower clock of the Raspberry Pi. To confirm this, we decided to run the test again with all processors running at 1GHz Results at 1GHz and Architecture Comparison We chose 1GHz because both the Raspberry Pi 0W and the BeagleBone Black were already running at that clock speed. This meant a change had to be made on the Raspberry Pi 2B and 3B. 46

55 Figure 4.2: Average CP-ABE decryption time vs. number of attributes. Just like encryption, CP- ABE decryption appears to be affected similarly by processor features. Decryption appears to be faster than encryption, however. This is simply done by running a script provided by the Linux distribution [31]. No errors were seen overclocking the Raspberry Pi 2B by 100MHz. With the BeagleBone Black and Raspberry Pi 2B running at the same core speed, the performance perfectly overlaps as seen in Figures 4.3 and 4.4. These boards share the same ARMv7-A architecture, so the additional cores of the Raspberry Pi do not offer any advantage in the absence of explicitly multi-threaded code. Eliminating any difference in clock speed between boards shows the performance difference of each architecture. We see a jump in performance between each generation of device in Figures 4.3 and 4.4. At 30 attributes the greatest jump in performance is between the ARMv6 Raspberry Pi 0W and the ARMv7-A SBCs with a difference of seconds (Figure 4.3). We will discuss the differences between the three architectures in Section CP-ABE Results Analysis Figure 4.1 shows that to keep encryption under a second, seven attributes is the maximum that can be supported for the Raspberry Pi 1B. The Raspberry Pi 1B and 0W share the same 47

56 Figure 4.3: Average CP-ABE encryption time vs. number of attributes using a 1GHz clock. Table 4.1: Single board computer specifications [28] [29] [30] [31] [32] [33] [34] (this is identical to Table 3.1 and is reproduced here for the reader s convenience) processor model, but differ in clock speed. If the Raspberry Pi 1B were clocked at 1GHz like the Raspberry Pi 0W, the maximum number of attributes increases to 10. Increasing clock speed is a way to improve CP-ABE performance on radio devices, but in a real-world application this may not be a viable solution. Higher clock speeds have a potential for lower stability, lower power efficiency, and increased heat. 48

57 Figure 4.4: Average CP-ABE decryption time vs. number of attributes using a 1GHz clock. Although processor speed contributes to encryption speed, when examining the 1GHz results in Figures 4.3 and 4.4 we see that the largest performance jump occurs between processor families. To explain these increases, we looked at processor implementation for differences that go beyond incremental device improvements. The largest of these jumps occurs between the ARMv6 and the ARMv7-A processors (see Table 4.1 for SBC specifications). The major difference between the two is the number of instructions issued per cycle. The ARMv7-A and ARMv8-A families are dual issue [41] [42] [43], while ARMv6 family is single issue [44] which results in lower instruction throughput. The performance jump between the ARMv7-A family and the ARMv8-A is more difficult to explain. According to ARM, the performance of the Cortex-53 used on the Raspberry Pi 3B is designed to be slightly better than a Cortex-A7 which is used on the Raspberry Pi 2B [43]. The performance difference appears to be significantly more than ARM suggests. Some of the documentation about the ARMv8-A and ARMv7-A processors involves a fee and a non-disclosure agreement. We expect that the explanation for the observed performance difference could be found in those documents. In any event, we were unable to account for the difference based on the information freely available. 49

58 It was expected that having multiple cores would affect the performance at least slightly, but this does not appear to be the case judging from Figures 4.3 and 4.4. The performance of the BeagleBone Black and the Raspberry Pi 2B are virtually the same. The cpabe toolkit was not written to take advantage of additional cores, but it was expected that the compiler optimization would do so to a minor degree. 4.2 AES Performance AES was designed to be simple with fast performance and this is evident in the benchmark [10]. Figures 4.5 and 4.6 show all AES data, with results displayed in millions of bytes per second processed. Throughput is slightly better using CBC mode over CTR mode, but overall the results are well above our prescribed minimum of 16,000 bytes per second. The lowest performer was the BeagleBone Black using cryptographic hardware running in CBC mode on 16 byte blocks at 1,162,060 bytes per second (labeled in the graphs as BeagleBone Black (Hardware)). This value indicates that radios with similar specifications to the SBCs will have no problem achieving an acceptable level of performance on AES. In this section we will examine the AES benchmark results in detail. In Section 4.2.1, we examine and compare the single-thread AES software performance of the SBCs. Section discusses the single-thread software AES performance of the SBCs when clocked at 1GHz. Multithreaded AES performance is discussed in Section Results using the hardware cryptographic module of the BeagleBone Black are examined in Section Further analysis of the complete data is given in Section AES Software Performance For ease of comparison, the results pertaining to only the single-threaded AES software benchmark results are shown in Figure 4.7. The Raspberry Pi 0W performance is very close to that of the 2B despite having an older architecture. Clock speed does appear to play a part in this, but it is not the only factor because the Raspberry Pi 1B is only slightly slower than the 2B. The performance of the BeagleBone Black almost matches the performance of the Raspberry Pi 3B in Figure 4.7. In the CP-ABE benchmark, the BeagleBone Black performed as well 50

59 Figure 4.5: AES CBC benchmark results. The quad-core Raspberry Pi 3B with multi-thread AES has the greatest throughput. CBC mode on the BeagleBone Black hardware cryptographic core has the least amount of throughput but is still over 1 million bytes per second. Our stated minimum for proper system operation was 16,000 bytes per second and all devices meet this easily. 51

60 Figure 4.6: AES CTR benchmark results. The quad-core Raspberry Pi 3B with multi-thread AES has the greatest throughput. Our stated minimum for proper system operation was 16,000 bytes per second and all devices meet this easily. 52

61 Figure 4.7: AES software benchmark comparison. This figure focuses only on the single-thread AES software benchmark from Figures 4.5 and 4.6. The BeagleBone Black and Raspberry Pi 3B are the best performers for the single-thread software benchmark. 53

62 Table 4.2: AES processor utilization recorded using GNU Time as the Raspberry Pi 2B using the same ARMv7-A architecture. Running the AES software benchmark, the performance of the BeagleBone Black is greater than the Raspberry Pi 2B. As seen in Table 4.2, processor utilization is 99% for almost all single-threaded software benchmarks. The Raspberry Pi 1B shows 95% utilization but is most likely due to processor overhead. The software results are in the millions of bytes per second processed, which is well above 54

63 our minimum performance metric of 16,000 bytes per second. There should be a comfortable margin on devices with similar capabilities to run AES encryption AES Software Performance at 1GHz As in the CP-ABE benchmark, we chose to run the AES benchmark again with all processors at 1GHz. The results are displayed in Figure 4.8. The BeagleBone Black outperforms the other SBCs tested in the single-threaded software benchmark when all are running at 1GHz AES Multi-Threaded Performance Throughput increases greatly when running multiple threads because AES parallelism can be exploited in multiple ways. There is parallelism at a block level where each function in a round can perform operations simultaneously (see Section 2.3.2). There is also parallelism in block cipher modes (see Section 2.3.3). When examining the code for OpenSSL to better understand what parallelism is exploited, we found that operations are performed sequentially at the block level. This means that the performance increase only involves parallelism in the block cipher modes. Using four threads results in about four times the throughput for CBC as seen in Figure 4.9. For any block in contiguous data, CBC relies on the encryption or decryption result of the previous block (see Section 2.3.3). The results show that each AES CBC thread is encrypting different data. This means that the multithreaded benchmark results for CBC are not representative for our use case. This is unexpected and was only discovered after our tests were completed. Data in radio systems should be treated as contiguous. Multi-threaded CTR results are representative for our use case. Unlike CBC, blocks do not rely on the previous block in contiguous data It should be noted that GNU Time reports 0% processor utilization this benchmark, which is incorrect. We suspect that GNU Time only supports single-threaded operations but have not found any documentation that states this. It is likely that all cores achieve utilization near 100% as performance is roughly four times that of the single thread benchmark. 55

64 Figure 4.8: AES 1GHz benchmark comparison. This figure focuses only on the single-thread 1GHz AES software benchmark from Figures 4.5 and 4.6. The BeagleBone Black has the highest throughput at 1GHz clock speed despite being an older device. 56

65 Figure 4.9: AES Multi-Threaded Benchmark Comparison. This figure focuses only on the multithreaded versus single-threaded AES software benchmark from Figures 4.5 and 4.6. Using four threads nearly quadruples the performance of the Raspberry Pi 2B and 3B. However, the multithreaded CBC results are not representative of our use case. 57

66 4.2.4 AES Cryptographic Core Performance For cipher block chaining using the BeagleBone Black cryptographic hardware, performance is surprisingly much lower than the software implementation. The bytes per second processed shown in Figure 4.10 is much higher than our minimum of 16,000 bytes per second, but we expected this to exceed the throughput of the software implementation. GNU Time shows lower processor use at 63% in all cases (see Table 4.2). This was expected and shows that the CPU is offloading some of the work of the encryption to the hardware core. Figure 4.10 shows running AES in counter mode matches the software benchmark found in Figure 4.7. This is unexpected as it was expected to be faster than the software implementation. Processor utilization is at 99% in Table 4.2, but it was expected to be lower as a hardware core should reduce work for the processor. This high processor utilization suggests that the cryptographic core is not being used for CTR AES Results Analysis All devices tested can decrypt at more than 16,000 bytes per second as required for smooth audio playback. In general, we suggest using CBC mode over CTR as it leaks less information if a non-unique IV is used [10]. If devices have multiple cores, CTR can offer a performance boost as block encryption and decryption can be split into multiple threads. Interesting performance comes from the BeagleBone Black. In the single-thread software test, the BeagleBone Black is comparable to the Raspberry Pi 3B. For example, the BeagleBone Black s throughput on the 16 kilobyte CTR benchmark with a 256-bit key is 37,218,990 bytes per second compared to the Raspberry Pi 3B at 31,014,910 bytes per second. We expected the BeagleBone Black to be comparable to the Raspberry Pi 2B since their processors are from same ARMv7-A family. The only architectural difference appears to be that the Cortex-A8 uses a high-performance 13 stage pipeline, while the Cortex-A7 and Cortex-A53 use an efficient 8 stage pipeline [42] [41] [43]. The larger pipeline did not affect CP-ABE performance, so there must be other design features not disclosed to the public that favor AES performance. 58

67 Figure 4.10: AES cryptographic hardware benchmark comparison. This figure focuses only on the BeagleBone Black single-thread AES software benchmark and cryptographic core benchmark from Figures 4.5 and 4.6. CBC performance is worse than software, but processor load is lower. CTR mode does not appear to be using the cryptographic core. 59

68 The BeagleBone hardware result for CBC was much lower than the software run. Texas Instruments response is that the cryptographic core runs at the L3 interconnect speed. Examining the functional block diagram in the processor datasheet does show the cryptography core is connected through a L3 interconnect [30]. If the core were in the ARM Cortex-A8 block, the performance would likely increase significantly. Because it communicates through the L3 interconnect, it is limited to the interconnect s speed of 200MHz [45]. According to a TI representative, the purpose of the cryptographic core is to decrease processor load. This leaves the processor free to perform other calculations and improve energy efficiency [45] [46]. This is confirmed by the processor utilization reported by GNU Time (Figure 4.2) where the BeagleBone Black with cryptographic hardware had a load of 63% compared to the 99% load in software mode. On the other hand, because counter mode matched software performance and processor load was near 100%, we suspect CTR hardware support in OpenSSL is not implemented. 60

69 CHAPTER 5. OBSERVATIONS Overall, the benchmark results show that devices similar to the tested SBCs can run a CP- ABE scheme. In this chapter we use the benchmark results to discuss how the scheme can be applied to existing and future radio systems. Our recommendations for application to radios in the field is discussed in Section 5.1. We describe a low-cost CP-ABE accessory in Section 5.2 which can be used to augment performance of low performance devices. Section 5.3 provides development suggestions for new radio devices using CP-ABE. 5.1 CP-ABE on Hardware in the Field There are several things that can be done to support a CP-ABE scheme on currently deployed radio devices. We describe a user interface that can easily be used on a radio to create a new talk group in Section The limit that should be placed on the number attributes for radio systems is explored in Section and ways to increase this number is discussed in Section User Interface Implementing CP-ABE on hardware already in the field will require a software change at minimum. In addition to key management, encryption, and decryption on the device, a user interface change needs to be made to allow the user to create the talk group. The creation of a new talk group can begin by choosing a pre-programmed talk group. A new talk group will be created with a subset of users from this selected talk group. The user then selects Create a New Talk Group in an options menu. The user then describes the users they wish to communicate with. This should include attributes, but also AND and OR which allows for a finer degree of control. This type of interaction can easily be done using an alphanumeric display, buttons, and selector knobs on a radio control panel. The radio is then ready to create a new talk group with a subset of users from the pre-programmed talk group. 61

70 5.1.2 Attribute Limits The types of radio devices can vary widely in a deployed system which can comprise a mix of older and newer hardware. A limit should also be placed on the number of attributes that can be selected to ensure performance is acceptable for two-way communication. We recommend that encryption or decryption should be under a second since radios are intended for real-time communication. This limit is decided by the device with the lowest CP-ABE performance. For example, the lowest performer of the tested SBCs is the Raspberry Pi 1B and seven attributes can be encrypted in one second (Figure 4.1). Because a few attributes can include (or exclude) many people in a talk group, seven attributes should work well for many radio systems. It is important to note that the processor family used on the Raspberry Pi 1B was released in 2004 [44] over thirteen years ago at the time of writing this thesis. This means radios designed over a decade ago can potentially be used in a CP-ABE system Applying Performance Improvements We presented three systems using CP-ABE in Section 1.3. The first system was the naïve system which uses a new CP-ABE ciphertext and AES key for each message sent. This system is secure, but performance can be improved. In Section 2.4.2, we mentioned that modifications to the access tree can improve decryption performance. These improvements were used in the cpabe toolkit. Results from our benchmark (Figures 4.1 and 4.2) show that decryption is faster than encryption. For example, the Raspberry Pi 1B can encrypt using seven attributes in one second but it can decrypt using ten attributes in one second. The other two systems we described in Section 1.3 take advantage of the faster decryption time. One system pre-generates CP-ABE keys while the system is not in use. The other system reuses the AES key for transmissions. For these systems where CP-ABE encryption is not performed for every message, the number of attributes is set by the device with the slowest CP-ABE decryption time. In our tests this would increase the maximum attributes from seven to ten. 62

71 Figure 5.1: Interface of a typical two-way radio. This radio features an alphanumeric display, which is essential for attribute selection in a CP-ABE system. 5.2 Low-Cost Accessory There are circumstances where devices cannot support CP-ABE with a firmware update. This includes radios that do not offer sufficient computational performance. The type of user interface on the radio is another factor. Radios with an alphanumeric display, like the one shown in Figure 5.1, are ideally suited to support a CP-ABE system. The user can select from a list of attributes to create a new talk group. Radios can also use a numeric display or forgo a display entirely and rely on a knob to select talk groups. Radios without alphanumeric displays will not be able to use a CP-ABE scheme with only a firmware update because available attributes cannot be displayed and selected. An alternative to a firmware update is to develop a radio accessory. Radios typically have a port where accessories can be connected to augment the capabilities of the device. A low-cost accessory can be developed to enable use of CP-ABE on an incompatible radio by using an SBC, a display, and a few buttons. If CP-ABE performance of a radio is lacking, an SBC such as the Raspberry Pi 3B can be used for CP-ABE tasks. According to benchmark results in Figures