Next Article in Journal
Chassis Assembly Detection and Identification Based on Deep Learning Component Instance Segmentation
Previous Article in Journal
Quadratic Spline Wavelets for Sparse Discretization of Jump–Diffusion Models
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

Measuring Performances of a White-Box Approach in the IoT Context

1
Department of Computer Science, Università degli Studi di Milano, via Celoria 18, 20133 Milan, Italy
2
Open Systems AG, Räffelstrasse 29, 8045 Zurich, Switzerland
*
Author to whom correspondence should be addressed.
Symmetry 2019, 11(8), 1000; https://doi.org/10.3390/sym11081000
Submission received: 12 June 2019 / Revised: 12 July 2019 / Accepted: 26 July 2019 / Published: 3 August 2019

Abstract

:
The internet of things (IoT) refers to all the smart objects that are connected to other objects, devices or servers and that are able to collect and share data, in order to “learn” and improve their functionalities. Smart objects suffer from lack of memory and computational power, since they are usually lightweight. Moreover, their security is weakened by the fact that smart objects can be placed in unprotected environments, where adversaries are able to play with the symmetric-key algorithm used and the device on which the cryptographic operations are executed. In this paper, we focus on a family of white-box symmetric ciphers substitution–permutation network (SPN)box, extending and improving our previous paper on the topic presented at WIDECOM2019. We highlight the importance of white-box cryptography in the IoT context, but also the need to have a fast black-box implementation (server-side) of the cipher. We show that, modifying an internal layer of SPNbox, we are able to increase the key length and to improve the performance of the implementation. We measure these improvements (a) on 32/64-bit architectures and (b) in the IoT context by encrypting/decrypting 10,000 payloads of lightweight messaging protocol Message Queuing Telemetry Transport (MQTT).

1. Introduction

The name internet of things (IoT), coined by the MIT researcher Kevin Ashton [1], usually refers to smart objects, connected through the internet to other sensors, devices and servers with which collect and/or share data for improving their functionalities. IoT can also be combined with other technologies, for example with cloud computing [2]. It is possible to create a sustainable smart home aiming to reduce resources’ consumption or develop specific applications in the medical field [3] such as wearable devices which monitor our physical conditions, specific devices used to check patients with chronic illnesses, and so on. Data collected by IoT devices need to be (a) processed to form informations by applying, for example, data mining techniques [4]; (b) evaluated in order to make decision by adopting agent based models [5,6], bayesian decision models [7], fuzzy logic [8] and so on; (c) protected from attacks, failures and leaks during communication [2].
Several issues have to be faced in securing IoT applications. An important example is given by the intrinsic constraints of the devices [9], that usually have a small amount of memory and cannot perform heavy computations. It is very likely to have such devices in non-protected environment, where an adversary can access them and perform attacks. In particular, she/he can perform an analysis of the controlled binary [10] or perform differential fault analysis [11,12]. Moreover, since these devices are connected, compromising one of them can open the way to botnet attacks [2,3]. We can observe that we are exactly in a white-box framework, and white-box cryptography [13] has been first developed to cope with the scenario in which an attacker can physically interact both with the implementation of the used cryptographic algorithm and with the device on which the encryption/decryption operations are executed. The usually studied scenario, namely black-box, in which the execution cannot be observed nor modified by the attacker, is not always suitable for IoT applications [14]. The reader can think about what happens in the context of digital rights management where discovering the key means to have the possibility to spread digital contents to people that have not payed such contents.
The effort of researchers towards white-box cryptographic schemes materialized with [13,15] where white-box versions of AES and DES have been implemented. Nevertheless, it is important to remark that these implementations have been attacked via algebraic attacks [16] (improved by [17]), [18,19,20]. Moreover, also Jacob et al. in [21] can easily break Chow’s implementations.
The need to have white-box algorithms for practical applications leads to develop some specific algorithms. Examples of block ciphers developed to be employed in the framework of white-box cryptography are ASASA [22] and SPACE [23]. However, these ciphers are not free of drawbacks or weaknesses. In particular, decomposition attacks can affect ASASA’s security while SPACE is heavy from a computational point of view [24]. An important step forward for white-box cryptography, was the development of substitution–permutation network (SPN)box [24], another block cipher that relies on internal block ciphers with the aim to reduce the computation time. In [9], the problem of intrinsic constraints on computational power and memory of IoT devices in unprotected environment is addressed. The authors refer to smart objects with limited computational power and memory that may contain sensitive data and can be easily lost or stolen. Differently from AES/DES white-box implementations, the authors do not decline a well-known cipher into the new framework, but they develop a new one, relying on a modification of Lai-Massey structure. The crucial point is that only the encryption is thought to be done on the IoT constrained device, while the decryption phase is supposed to be done on a computer or server and in a black box scenario. In [25] the authors refer to embedded distributed devices which collect and securely send information to centralized servers. Subsequently, these servers decrypt and process all the information. As previously mentioned, the collected information may be sensitive and it is possible for an attacker to get control of the whole device. The scheme proposed in [25] is lightweight and suitable for constrained devices. In particular, such a new design has the following peculiarities:
  • the employed operations are very simple; they essentially consist of lookup tables and bit operations;
  • the lookup tables and the structure containing sensitive data are small in memory;
  • the provided security is medium-level (∼ 2 63 ) and protection is ensured for reasonable amount of time;
  • it is possible to update the key at small costs.
The scheme is based on a Fesitel structure, but it adds two bijections, as a defence against attacks. Moreover, to cope with structural cryptanalysis [25,26] different size components are used.
This paper improves of a previous work entiteled “White-box Cryptography: A Time-security Trade-off for the SPNbox Family” [27], presented by F.Cioschi, N.Fornari and A.Visconti at the 2nd International Conference on International Conference on Wireless, Intelligent and Distributed Environment for Communication (WIDECOM 2019). In this paper, we (a) introduce the white-box approach in the IoT context, explaining the importance of protecting data in an environment where attackers have full control over the whole system; (b) explain the importance of having a fast black-box implementation of a white-box cipher; (c) summarize our previous idea [27] explaining how to modify the internal block ciphers of the SPNbox family in order to increase the size of the key space; (d) measure the performance of a black-box implementation (server-side) on 32- and 64-bit architectures and by encrypting/decrypting 10,000 payloads of a lightweight messaging protocol—i.e., MQTT—which contains the data sent over the internet.
The remainder of the paper is organized as following. In Section 2, block ciphers are introduced. In Section 3, we present several white-box implementations and related attacks published in literature. In Section 4 and Section 5, we summarize two block ciphers’ families, namely, SPACE and SPNbox, which are white-box friendly by design. In Section 6, we explain the importance of increasing the number of bits of the key used in each round. In Section 7, the testing activities are presented. Finally, Section 8 is devoted to discussion and conclusions.

2. Block Ciphers

There exist two main families of block ciphers: SPN and Feistel network. The main difference between them is that Feistel networks play only with one half of the cipher state in each round.

2.1. Substitution-Permutation Networks

A SPN is a design for block ciphers proposed by Shannon in [28], where he suggested to use multiple mixing layers interleaving substitutions and permutations. Although weak on its own, applying substitutions and then permutations presents good “mixing” properties. Substitutions contribute to local confusion and permutations spread such a local confusion to the more distant subblocks, thus providing diffusion [28]. If a single input bit is flipped, it affects the m output bits of a specific S-box which, subsequently, are sent to different S-boxes by a permutation. Considering the output of such a network, about fifty percent of the bits are affected by this change. Therefore an outcome of a single bit change at the input is difficult to predict, especially if the bit of the secret key are XORed into the block between the encryption layers. In order to get better diffusion properties, several block ciphers adopt linear (as in the case of AES) or affine mappings instead of permutations.
Definition 1.
Let ϕ : ( F 2 ) r × ( F 2 ) l ( F 2 ) r , with r = b t be a block cipher with N rounds. Let k ( F 2 ) l be the cipher key and ( k ( 0 ) , , k ( N ) ) be the N + 1 round keys generated by k through the key schedule.
Then ϕ is an SPN block cipher if
ϕ k ( x ) = τ N τ N 1 τ 0 ( x ) x ( F 2 ) r
where τ i = σ k ( i ) λ ( i ) γ ( i ) and
  • γ ( i ) : ( F 2 t ) b ( F 2 t ) b is a non linear substitution
  • λ ( i ) A G L ( ( F 2 ) r ) where A G L ( ( F 2 ) r ) is the subgroup of the affine transformations of ( F 2 ) r
  • σ k ( i ) is the addition with the round key
σ k ( i ) : ( F 2 ) r ( F 2 ) r x x k ( i )
where by we denote the bitwise addition (XOR).

2.2. Feistel Networks

A Feistel network is a block cipher introduced by H. Feistel and D. Coppersmith in 1973 [29] which has the advantage of having the encryption and decryption functions almost identical, making the implementation easier and cheaper compared to translation based ciphers.
Let us define the following functions before describing the encryption process.
Definition 2.
Let π t be a projection, with t { 1 , , 2 n } , defined as:
π t : F 2 n F t ( x 1 , , x 2 n ) ( x 1 , , x t )
Considering x F 2 n as a vector of bits, we can use projection π t to choose the t most significant bits of x.
Definition 3.
Let ϱ t be a projection, with t { 1 , , 2 n } , defined as:
ϱ t : F 2 n F t ( x 1 , , x 2 n ) ( x 2 n t + 1 , , x 2 n )
In the same way, using projection ϱ t we can choose the t least significant bits of x.
Given m F 2 n (a message) and k F l (a secret key), for some positive integer l, the encryption process works as follows:
  • N + 1 round keys k 0 , . . k N are generated from k by means of the key schedule
  • message m is split into a left block and right block, initialized as
    L 0 = π n ( m ) R 0 = ϱ n ( m )
  • for i { 1 , , N + 1 } the round function is applied in the following way:
    L i = R i 1 R i = L i 1 F ( R i 1 , k i 1 )
  • final ciphertext c is ( R N + 1 , L N + 1 ) .
Encryption and decryption only differ in the reverse order of the round keys, as a matter of fact the decryption of ciphertext ( R N + 1 , L N + 1 ) is accomplished computing for i { N , N 1 , , 0 }
R i = L i + 1 L i = R i + 1 F ( L i + 1 , k i )
An advantage of Feistel networks is that Feistel function F is non-necessarily invertible.This can be clearly seen by analyzing how encryption and decryption work (see Equations (1) and (2)).

3. The White-Box Approach

The White-Box approach aims to avoid key recovery attacks by embedding the cryptographic key into a robust representation of the cipher. Consider a block cipher ϕ . We compute a map ψ : F n F n such that, given a key k ¯ F l , it holds ϕ ( x , k ¯ ) = ψ ( x ) x F n . If an attacker knows even both ϕ and ψ , it should be very hard for him to find out the key.
Example 1.
Let ϕ and ψ be defined as follows:
ϕ ( x ) : = k + x mod 4 x { 0 , , 3 } ψ ( x ) : = S [ x ] S = [ 3 , 0 , 1 , 2 ]
If k = 3 , we can consider ψ as a white-box implementation of ϕ, by representing ψ as a lookup table.
The first white-box AES implementation has been proposed by Chow et al. in [13]. The authors suggest that key extraction can be avoided by a careful use of lookup tables. In particular, given a secret key and a block cipher, it is possible to create a lookup table which maps the plaintext in a corresponding ciphertext. In some cases, this lookup table may be huge and unusable due to its dimension. Therefore, a block cipher ϕ can be represented as a network of smaller lookup tables (see Figure 1) that have to be read in a particular order [13]. Unfortunately, in the white-box framework an adversary has full access to these tables, exposing the cipher to possible attacks. Since there is no reason to make an attacker’s life easier, tables can be protected by means of internal encodings [13]. This means that a map is composed after table i and its inverse before table ( i + 1 ) , leaving the ciphertext unchanged. However, internal encoding does not protect against code-lifting attacks. Indeed, an attacker may recover the tables of the cipher and understand their concatenation order. Doing so, she/he is able to decrypt messages even though he had not recovered the secret key. Therefore, another protection is required: external encoding. Internal and external encodings are also discussed in [30], while a different approach, based on polynomial algebra techniques [31], gave rise to a perturbated white-box implementation of AES [32], broken by [33] in 2010.
Chow’s work is a milestone for white-box cryptography and its framework has also been used by some subsequent works such as [34,35]. However, researchers found attacks also for these new approaches:
  • White-Box AES Implementation: Chow [13]; Attack: [16]; Work Factor: 2 30 ;
  • White-Box AES Implementation: Karroumi [34]; Attack: [18,20]; Work Factor: 2 22 ;
  • White-Box AES Implementation: Xiao Lai [35]; Attack: [18]; Work Factor: 2 32 ;
  • White-Box AES Implementation: Xiao Lai [35] generic linear version; Attack: [18]; Work Factor: 2 38 ;
  • White-Box AES Implementation: Xiao Lai [35] affine/non-affine version; Attack: [19]; Work Factor: at least 2 49 .
The attacks listed above may require to know the internal data representation and sometimes this means to produce a significant reverse engineering effort. An improved AES implementation is given in [36]. This implementation is immune to attacks described in [16,18] but it is not to the one presented in [37].
The first paper aiming to break all white-box implementations belonging to the framework introduced in [13] is [19], but it has the weak point to require some additional hypotheses. Differently, Derbez et al. [38] breaks all the papers in Chow’s framework by solving the affine equivalence problem (see [39,40]). Chow’s framework has also been used by [41] and subsequently attacked by [42].
A significant advance from the attacker’s point of view became feasible by shifting the focus from the attacks previously described to side channel attacks [43]. In particular, new approaches to verify the security of a white-box implementation have been proposed in [44] where Bos et al. present differential fault analysis (DFA) and differential computational analysis (DCA) attacks (further information on fault-injection and differential power analysis attacks can be found in [45,46] respectively). In addition, in [47,48] the authors explained more formally why DCA is effective against linear and nibble encoding, Rivain and Wang [43] provide an extensive analysis on the effectiveness of DCA, finally Biryukov and Udovenko [49] give a general protection method for white-box implementations against DCA.
Obfuscation techniques or the randomization of the location of the lookup tables can be used to enhance security of white-box algorithms [50], while [51] examines how these techniques are successful against both DCA and differential power attacks (DPA). The paper [52] exploits noncommutative groups to obfuscate operation that should be made on commutative ones and it is employed in the IoT framework. Finally, an evaluation on software protections to white-box implementations is provided by [51].
Some improvements to DCA have been developed by [43,53]. The first one extends DCA to successfully address implementations using masking and shuffling techniques [53]. The second one provide a DCA-like collision attack with a good complexity [43].
Some paper such as [54,55,56] address the problem of incompressibility or code hardness. The idea is that an attacker in the white-box framework should not be able to rewrite the code of some implementation in order to decrease the code-hardness. In [54] two incompressible white-box schemes called “WhiteKey” and “WhiteBlock” are introduced and one instance for each scheme is provided (called PuppyCipher and CoureurDesBois respectively), [55] describes the concept of code-hardness, time-hardness and memory-hardness, while [56] provides a new incompressible white-box implementation based on the assumption of one-way permutations.
We conclude our extensive analisys of implementations and attacks, citing a white-box signature scheme [57] and the methods [58] used to attack the most resistant implementation submitted to the white-box competition called “CHES 2017 CTF Challenge”.
In the sequel, we will analyze in detail two family of white-box cipher called SPACE (Section 4) and SPNbox (Section 5).

4. SPACE: A Block Cipher

SPACE is a block cipher developed by Bogdanov and Isobe in [23], that is based on a Feistel network. This cipher is designed so that security against key extraction in the white-box context reduces to the well studied problem of key recovery for block ciphers in the standard black-box setting.
SPACE is a generalized Feistel network [29]. Given a message m F n and a secret key k K , it encrypts m to a ciphertext c F n . In describing SPACE, three quantities are often employed: n , n a , n b N . In particular, in [23] n = 128 , n a { 8 , 16 , 24 , 32 } and n b = n n a .
We summarize here the encryption procedure:
  • The state X r at round r can be seen as given by l = n / n a vectors x i r F n a so
    X r = { x 0 r , x 1 r , , x l 1 r } .
  • X 0 = m , so it is initialized with the plaintext.
  • For r { 1 , , R + 1 } the state is updated this way:
    X r + 1 = F n a r ( x 0 r ) ( x 1 r x 2 r x l 1 r ) x 0 r
    where F n a r : F n a F n b is the Feistel function and is the concatenation.
  • X R + 1 = c so we have found the ciphertext.
At each encryption round, the Feistel function takes x 0 r as input. Then F n a r ( x 0 r ) is added to the rest of the state ( x 1 r x l 1 r ) . The first n b bits of the new state are given by the result of this operation. The last n a are filled with x 0 r .
Now, consider π t be the projection of Definition 2 and the Feistel function F n a r used by SPACE, specified in Definition 4.
Definition 4.
Let ϕ k be a block cipher and r the round number represented in binary with n b digits (so we see it as an element of F n b ). The Feistel function F n a r is defined as
F n a r ( x ) : F n a F n b x ( π n b ( ϕ k ( 0 , , 0 n b x ) ) ) r .
We give a specific notation for the round independent part of F n a .
Definition 5.
The round independent part of the Feistel function F n a is
F n a : F n a F n b x π n b ( ϕ k ( 0 , , 0 n b x ) )
Notice that, differently from traditional Feistel networks, SPACE does not use round keys. There is one secret key k used by ϕ k . This secret key cannot be hardcoded, hence F n a is implemented as a look-up table. The reader might ask himself the reason for designing SPACE over another block cipher ϕ k when ϕ k could be directly implemented as a look-up table. It turns out that this second possibility cannot be developed. If we were to implement ϕ k as a look-up table we would need 2 n · n bits of space:
( 0 , 0 , 0 ) n ϕ k ( 0 , 0 , 0 ) n ( 0 , 0 , 1 ) ϕ k ( 0 , 0 , 1 ) ( 1 , 1 , 1 ) ϕ k ( 1 , 1 , 1 )
For n = 128 the construction of such a look-up table is practically impossible. Therefore Bogdanov and Isobe propose to truncate the output of ϕ k , computed over a smaller domain (see Figure 2):
Since the first n b zeros are used as padding in order to form an n-bit input to provide to ϕ k , it is completely useless to store them, hence the look-up table implementation needs 2 n a · n b bits. Thus, the size of the tables for different values of n a { 8 , 16 , 24 , 32 } —SPACE( n a , R), where R is the suggested number of rounds—is the following:
  • SPACE-(8,300); Table: 3.84 KB
  • SPACE-(16,128); Table: 918 KB
  • SPACE-(24,128); Table: 218 MB
  • SPACE-(32,128); Table: 51.5 GB
Notice that (1) AES white-box implementations of Chow et al. [13] and Xiao Lai [35] has a table of 752 KB and 20.5 MB respectively; (2) not all n a values are suitable, indeed, for n a = 32 and n a = 24 the size of the table is not good enough to be used in practice. On the contrary, for n a = 16 the table has the same size of that described in [13].

5. The SPNbox Family

The SPACE family of space-hard block ciphers [23] benefits of the Feistel structure from a security point of view and prevents the use of parallel execution (see Section 4). However, as suggested in [24], using an SPN-type design it is possible to satisfy the requirement of parallelism maintaining a suitably high level of space hardness. Thus, Bogdanov et al. described the SPNbox family of space-hard block ciphers [24]. Let us briefly explain their idea.
SPNbox- n i n is a substitution-permutation network (SPN) with a block length of n bits, a k-bit secret key, and based on n i n -bit substitution boxes.
State:
The state of SPNbox- n i n is representable as a vector of t = n / n i n elements of n i n bits each:
X = { X 0 , , X t 1 }
Key Schedule:
The k-bit master key is expanded, k 0 , , k R n i n round keys of n i n bits, by means of a Key Derivation Function (KDF)—e.g., PBKDF2 [59,60,61,62], ARGON2 [63], Scrypt [64], and so on:
( k 0 , , k R n i n ) = K D F ( k , n i n · ( R n i n + 1 ) )
Round Transformation:
We encrypt a plaintext X 0 and we get a ciphertext X R , by using the following R transformations—e.g., R = 10 :
X R = ( r = 1 R ( σ r θ γ ) ) ( X 0 )
The nonlinear layer γ is a substitution layer where t identical bijective n i n -bit S-boxes depending on the key are applied to the state:
γ : F ( 2 n i n ) t F ( 2 n i n ) t ( X 0 , , X t 1 ) ( S n i n ( X 0 ) , , S n i n ( X t 1 ) )
These identical S-boxes are constituted by an internal small block cipher of block length n i n bit.
The linear layer θ , a diffusion layer, applies a t × t MDS matrix to the state:
θ : F ( 2 n i n ) t F ( 2 n i n ) t
( X 0 , , X t 1 ) ( X 0 , , X t 1 ) · M n i n
The affine layer σ r takes the state and adds round-dependent constants to it:
σ r : F ( 2 n i n ) t F ( 2 n i n ) t
( X 0 , , X t 1 ) ( X 0 C 0 r , , X t 1 C t 1 r ) ,
with C i r = ( r 1 ) · t + i + 1 for 0 i t 1 .
The Underlying Small Block Ciphers:
The identical n i n -bit S-boxes in the γ layer (which depend on the key) are block ciphers. They are based on the round transformation of AES and they are formed by R n i n rounds operating on a state x = { x 0 , , x l 1 } of l bytes, where l = n i n / 8 :
S n i n : F ( 2 8 ) l F ( 2 8 ) l
x ( i = 1 R n i n ( A K i M C n i n S B ) ) ( A K 0 ( x ) )
where SB, MC and AK indicate the AES transformations SubBytes, MixColumns and AddRoundKey, respectively. Notice that (a) the number of rounds R n i n that [24] suggests are R 32 = 16, R 24 = 20, R 16 = 32 and R 8 = 64; (b) different matrices are employed in the M C n i n round transformation. More precisely, for n i n = 32 we use the M C matrix of AES, while in the other cases a sub-matrix of M C is used. If n i n = 8, M C n i n is the identity map’s matrix. Note that, as for the Feistel function in SPACE, in the white-box setting the small block ciphers S n i n are implemented as lookup tables.

6. Issues and Possible Solutions

Although the white-box implementation of the cipher is very important, it may have some limitations due to the key embedded into the device. If several devices have to communicate with a server and such devices do not support Transport Layer Security (TLS) protocol due to insufficient resources, the server needs to manage a number of keys (pre-shared or not) in order to decrypt the messages. In a white-box context this means having a number of different implementations that run on our server and this is not a good idea. Therefore, the server will be provided with a fast black-box implementation of the cipher.
Figure 3 helps us to visualize this idea, where a white-box implementation runs on a number of devices and a fast black-box implementation runs on our server.
In order to design a fast black-box implementation of a white-box cipher, we modify the inner round described in Section 5, increasing the number of bits of the key used in each round. In particular, we replace the AES’ ShiftRow transformation, omitted by [24], with a key-dependent circular bit shift transformation (see Figure 4 and Figure 5).
If we are shifting eight bits of the state, i.e., n i n = 8, three bits are required to execute the circular shift. Thus, we use 11 bits of the key in each round i: eight of them for the AK i transformation and three for the BitShift transformation. If the state doubled, tripled, or quadrupled, i.e., n i n = 16, 24, 32, the bits of the key used are 11 × 2 = 22 , 11 × 3 = 33 and 11 × 4 = 44 respectively.
Notice that the implementation of [24] employs the AES-NI instructions, while the idea described in this paper does not. In the encryption phase ( n i n = 32, 24, 16), the matrices involved in the computation of the MixColumns transformation ( A 24 , and A 16 for short) are sub-matrices of that used in AES ( A 32 ). On the contrary, in the decryption phase, we need to invert A 24 and A 16 . Since their inverse matrices are not sub-matrices of A 32 1 and the decryption instruction of AES-NI is based only on A 32 1 , for n i n = 24, 16 we cannot use the AES-NI instructions. Anyway, in IoT context, the impossibility of using AES-NI instructions is not a problem in itself because not all IoT devices support this instruction set.

7. Testing Activities

The testing activity reported is twofold. In the first part, we measure the performance of internal layer γ (see Algorithm 1)—the external part (layer θ and σ ) is exactly the same as in [24], so it would be pointless to evaluate it.
Algorithm 1: Layer γ with BitShift transformation.
Symmetry 11 01000 i001
We run our code on laptops with different hardware configurations. More precisely, our laptops are equipped with
  • Intel® CoreTM i3-330M, 2.13 GHz processor with 3 MB SmartCache, 8 GB RAM and Ubuntu 18.04.1 LTS 64-bit. The source code has been compiled with GCC 7.3.0 with -O3 optimization enabled (see Table 1);
  • Intel® CoreTM i3-350M, 2.26 GHz processor with 3 MB SmartCache, 8 GB RAM and Ubuntu 18.04.2 LTS 64-bit. The source code has been compiled with GCC 7.4.0 with -O3 optimization enabled (see Table 2);
  • Intel® CoreTM i7-2860QM, 2.50/3.60 GHz processor with 8 MB SmartCache, 16 GB RAM and Kubuntu 18.10 64-bit. The source code has been compiled with GCC 7.3.0 with -O3 optimization enabled (see Table 3);
  • Intel® CoreTM i7-5500U, 2.40/3.00 GHz processor with 4 MB Cache, 8 GB RAM and Ubuntu 18.04.2 LTS 64-bit. The source code has been compiled with GCC 7.4.0 with -O3 optimization enabled (see Table 4);
  • Intel® CoreTM i7-8550U CPU, 1.80/4.00 GHz processor with 8 MB SmartCache, 32 GB RAM and Ubuntu 18.04.2 LTS 64-bit. The source code has been compiled with GCC 7.4.0 with -O3 optimization enabled (see Table 5);
  • Intel® CoreTM i3-350M, 2.26 GHz processor with 3 MB SmartCache, 4 GB RAM and Debian GNU/Linux 9 32-bit. The source code has been compiled with GCC 6.3.0 with -O3 optimization enabled (see Table 6);
In the second part, as explained in Section 6, we examine the cipher in the IoT context, where black-box and white-box implementations are involved.

7.1. 32/64-Bit Architectures

We compared the performance of internal layer γ (yellow rectangles of Figure 5) with and without BitShift transformation (green rectangles of Figure 5) for different n i n sizes. We avoid the operations involved in θ and σ layers.
Table 1, Table 2, Table 3, Table 4, Table 5 and Table 6 show the time required to encrypt/decrypt one million of different plaintexts (fixed size of 128 bits) using the same key (randomly chosen). Notice that in addition to the key bits needed for the initial AddRoundKey A K 0 , SPNbox layer γ uses 512 key bits—i.e., 512 bit = 16 round × 32 bit ( n i n = 32), or 512 bit = 32 round × 16 bit ( n i n = 16), or 512 bit = 64 round × 8 bit ( n i n = 8). Therefore, we set to 512 the minimum amount of key bits to be used in our solution. In particular, we will execute: 12 rounds ( R n i n = 12), using 528 key bits ( n i n = 32); 24 rounds ( R n i n = 24), using 528 key bits ( n i n = 16); and finally 47 rounds ( R n i n = 47), using 517 key bits ( n i n = 8).
Our testing activities show that implementations with BitShift are generally faster than those without it. In particular, several cases show that the improvement in the execution time exceeds 20%. Only in Table 5, n i n = 8, encryption and decryption, we find a different result.

7.2. IoT Environment

The testing activity has been performed using MQTT [65], a lightweight communication protocol designed for small sensors and mobile devices in low bandwidth environments. By default data are sent in clear text over the internet, thus we encrypt data contained in the payload. We measure the performance of layer γ as described in Algorithm 2. More precisely, we compare the performances with and without BitShift transformation for different n i n —size of 32, 16, and 8 bits—encrypting one million of different plaintexts—size of 16, 64, 256, and 1024 bytes—using the same key. Then, we send one hundred MQTT messages, each of which contains 10,000 encrypted payloads. Finally, adopting the same approach, the server collects and decrypts the same number of MQTT messages with encrypted payloads.
Algorithm 2: MQTT: testing activity executed for each payload (16, 64, 128, and 1024 bytes).
Symmetry 11 01000 i002
Our testing activity has been executed on a machine equipped with an Intel® Core™ i7-6500U CPU @ 2.50 GHz × 4 processor, with 12 GB SDRAM DDR4-2133, Intel® HD Graphics 520 (Skylake GT2) GPU and operating system Ubuntu™ 18.04.2 TLS. We used Eclipse Mosquitto™ [66] version 1.4.15, which implements the MQTT protocol versions 3.1.1. The source code has been compiled with GCC 7.4.0, “-O3” optimization enabled. Table 7 summarizes the results obtained.
In particular, for the encryption phase, we got a highest gain (23.680%) in the case of 128-byte payload and n i n = 16 , while the highest loss ( 9.060 % ) in the case of a 64-byte payload and n i n = 8 . For the decrypt phase, the highest gain ( 22.091 % ) is obtained with a 16-byte payload and n i n = 16 , and the highest loss ( 5.607 % ) with a 128-byte payload and n i n = 8 . Notice that the case n i n = 8 turned out to be the worst one.

8. Conclusions

In the era of the internet of things, the involved devices are usually lightweight, so they cannot perform heavy computations nor store a huge amount of data. In addition, these data might be sensitive—energy consumptions, medical records, and so on—and could be sent in an unprotected environment. In a white-box scenario, an attacker could easily read these data because she/he has full access to the whole execution platform and white-box cryptography can be used to secure data in this specific context.
Considering the effectiveness of side-channel attacks, new ciphers has been designed with white-box attack model in mind. In this paper, we focused on the SPNbox family [24], suggesting how to increase the number of key bits used in each round and showing that this improvement affects the performance of the cipher. The introduction of a key-dependent circular bit shift transformation helped us to increase the keyspace and to reduce the number of rounds of the cipher, reducing the execution time too.
We described and analyzed the performance of the modified cipher in the IoT context, where both white-box and black-box implementations may be required. In particular, we measured its performance (a) on 32/64-bit architectures and (b) encrypting the payload of an IoT messaging protocol. Our testing activities have been executed on consumer laptops. The results obtained encrypting and decrypting one million of different 128-bit plaintexts on 32/64-bit architectures showed that the execution time for layer γ is reduced up to 22% while the highest loss is about 8%.
Moreover, the testing activities performed with lightweight protocol MQTT had a gain of about 23% and 22% (encryption and decryption phase, respectively) while a loss of about 9% and 5%. In all our testing activities the case n i n = 8 turns out to be the worst one.
Possible future works are try to (a) understand in details why current implementation fails for n i n = 8 and (b) implement a communication protocol based on Transport Layer Security pre-shared key ciphersuites (TLS-PSK) in order to compare the performance of white-box implementations with those of lightweight ciphers.

Author Contributions

All the authors contributed equally to the work. D.G.V.A., F.C., and A.S. wrote the code and executed testing activities; M.C., N.F., and A.V. wrote the manuscript; All the authors discussed the results and provided critical comments; A.V. supervised the testing activities.

Funding

This research received no external funding and the APC was funded by Università degli Studi di Milano, Piano di Sostegno alla Ricerca 2018.

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Ashton, K. That ‘internet of things’ thing. RFID J. 2009, 22, 97–114. [Google Scholar]
  2. Harini, S.; Jothika, K.; Jayashree, K. A Survey on Privacy and Security in Internet of Things. Int. J. Innov. Eng. Technol. 2017, 8, 129–134. [Google Scholar]
  3. Bertino, E. Data Security and Privacy in the IoT. EDBT 2016, 2016, 1–3. [Google Scholar]
  4. Tsai, C.; Lai, C.F.; Chiang, M.C.; Yang, L.T. Data mining for internet of things: A survey. IEEE Comm. Surv. Tut. 2013, 16, 77–97. [Google Scholar] [CrossRef]
  5. Schlesinger, M.; Parisi, D. The agent-based approach: A new direction for computational models of development. Dev. Rev. 2001, 21, 121–146. [Google Scholar] [CrossRef]
  6. Visconti, A.; Tahayori, H. Artificial immune system based on interval type-2 fuzzy set paradigm. Appl. Soft Comput. 2011, 11, 4055–4063. [Google Scholar] [CrossRef]
  7. Lee, S.; Kyon-Mo, Y.; Sung-Bae, C. Integrated modular Bayesian networks with selective inference for context-aware decision making. Neurocomputing 2015, 163, 38–46. [Google Scholar] [CrossRef]
  8. Visconti, A.; Tahayori, H. Detecting misbehaving nodes in MANET with an artificial immune system based on type-2 fuzzy sets. In Proceedings of the 2009 International Conference for Internet Technology and Secured Transactions, (ICITST), London, UK, 9–13 November 2009. [Google Scholar]
  9. Shi, Y.; Wei, W.; He, Z.; Fan, H. An ultra-lightweight white-box encryption scheme for securing resource-constrained IoT devices. In Proceedings of the 32nd Annual Conference on Computer Security Applications, Los Angeles, CA, USA, 5–8 December 2016; ACM: New York, NY, USA, 2016. [Google Scholar]
  10. Shamir, A.; Van Someren, N. Playing “hide and seek” with stored keys. In Proceedings of the Conference Financial Crypto 1999 (FC’99), Anguilla, British West Indies, 22–25 February 1999; Franklin, M., Ed.; Springer: Heidelberg, Germany, 1999; pp. 118–124. [Google Scholar]
  11. Boneh, D.; DeMillo, R.A.; Lipton, R.J. On the importance of checking cryptographic protocols for faults (extended abstract). In Proceedings of the Conference EUROCRYPT97, Konstanz, Germany, 11–15 May 1997; Fumy, W., Ed.; Springer: Heidelberg, Germany, 1997; pp. 37–51. [Google Scholar]
  12. Biham, E.; Shamir, A. Differential fault analysis of secret key cryptosystems. In Proceedings of the Conference CRYPTO97, Santa Barbara, CA, USA, 17–21 August 1997; Kaliski, B.S., Ed.; Springer: Heidelberg, Germany, 1997; pp. 513–525. [Google Scholar] [Green Version]
  13. Chow, S.; Eisen, P.; Johnson, H.; Van Oorschot, P.C. White-box cryptography and an AES implementation. In Proceedings of the International Workshop on Selected Areas in Cryptography 2002, St. John’s, NL, Canada, 15–16 August 2002; Nyberg, K., Heys, H., Eds.; Springer: Berlin, Germany, 2002; pp. 250–270. [Google Scholar]
  14. Cho, J.; Kyu Young, C.; Dukjae, M. Hybrid WBC: Secure and efficient encryption schemes using the White-Box Cryptography. IACR Cryptol. ePrint Arch. 2015, 2015, 800. [Google Scholar]
  15. Chow, S.; Eisen, P.; Johnson, H.; Van Oorschot, P.C. A white-box DES implementation for DRM applications. In Proceedings of the ACM Workshop on Digital Rights Management, Washington, DC, USA, 18 November 2002; Feigenbaum, J., Ed.; Springer: Berlin, Germany, 2002; pp. 1–15. [Google Scholar]
  16. Billet, O.; Henri, G.; Charaf, E. Cryptanalysis of a white box AES implementation. In Proceedings of the International Workshop on Selected Areas in Cryptography, Waterloo, ON, Canada, 9–10 August 2004; Handschuh, H., Hasan, M.A., Eds.; Springer: Berlin, Germany, 2004; pp. 227–240. [Google Scholar]
  17. De Mulder, Y.; Roelse, P.; Preneel, B. Revisiting the BGE attack on a white-box AES implementation. IACR Cryptol. ePrint Arch. 2013, 2013, 450. [Google Scholar]
  18. De Mulder, Y.; Roelse, P.; Preneel, B. Cryptanalysis of the Xiao–Lai white-box AES implementation. In Proceedings of the International Conference on Selected Areas in Cryptography 2012, Windsor, ON, Canada, 15–16 August 2012; Knudsen, L.R., Wu, H., Eds.; Springer: Berlin, Germany, 2012; pp. 34–39. [Google Scholar]
  19. Michiels, W.; Gorissen, P.; Hollmann, H.D.L. Cryptanalysis of a generic class of white-box implementations. In Proceedings of the International Workshop on Selected Areas in Cryptography 2008, Sackville, NB, Canada, 14–15 August 2008; Avanzi, R.M., Keliher, L., Sica, F., Eds.; Springer: Berlin, Germany, 2008; pp. 414–428. [Google Scholar]
  20. Lepoint, T.; Rivain, M.; De Mulder, Y.; Roelse, P.; Preneel, B. Two attacks on a white-box AES implementation. In Proceedings of the International Conference on Selected Areas in Cryptography 2013, Burnaby, BC, Canada, 14–16 August 2013; Lange, T., Lauter, K., Lisoněk, P., Eds.; Springer: Berlin, Germany, 2013; pp. 265–285. [Google Scholar]
  21. Jacob, M.; Boneh, D.; Felten, E. Attacking an obfuscated cipher by injecting faults. In Proceedings of the ACM Workshop on Digital Rights Management, 2002, Washington, DC, USA, 18 November 2002; Springer: Berlin, Germany, 2002; pp. 16–31. [Google Scholar]
  22. Biryukov, A.; Bouillaguet, C.; Khovratovich, D. Cryptographic schemes based on the ASASA structure: Black-box, white-box, and public-key (Extended Abstract). In Advances in Cryptology, Proceedings of the ASIACRYPT 2014, Kaohsiung, Taiwan, 7–11 December 2014; Sarkar, P., Iwata, T., Eds.; Springer: Berlin, Germany, 2014; pp. 63–84. [Google Scholar]
  23. Bogdanov, A.; Takanori, I. White-box cryptography revisited: Space-hard ciphers. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, Denver, CO, USA, 12–16 October 2015; ACM: New York, NY, USA, 2015; pp. 1050–1069. [Google Scholar]
  24. Bogdanov, A.; Takanori, I.; Tischhauser, E. Towards practical whitebox cryptography: Optimizing efficiency and space hardness. In Proceedings of the ASIACRYPT 2016, Hanoi, Vietnam, 4–8 December 2016; Cheon, J.H., Tsuyoshi, T., Eds.; Springer: Berlin, Germany, 2016; pp. 126–158. [Google Scholar]
  25. Shi, Y.; Wei, W.; Fan, H.; Au, M.H.; Luo, X. A Light-Weight White-Box Encryption Scheme for Securing Distributed Embedded Devices. IEEE Trans. Comput. 2019, in press. [Google Scholar] [CrossRef]
  26. Biryukov, A.; Shamir, A. Structural cryptanalysis of SASAS. J. Cryptol. 2014, 23, 505–518. [Google Scholar] [CrossRef]
  27. Cioschi, F.; Fornari, N.; Visconti, A. White-Box Cryptography: A Time-Security Trade-Off for the SPNbox Family. In Proceedings of the 2nd International Conference on Wireless Intelligent and Distributed Environment for Communication (WIDECOM 2019), Milan, Italy, 11–13 February 2019; Woungang, I., Dhurandher, S., Eds.; Springer: Cham, Switzerland, 2019; pp. 153–166. [Google Scholar]
  28. Shannon, C.E. Communication theory of secrecy systems. Bell Syst. Tech. J. 1949, 28, 656–715. [Google Scholar] [CrossRef]
  29. Feistel, H. Cryptography and computer privacy. Sci. Am. 1973, 228, 15–23. [Google Scholar] [CrossRef]
  30. Lee, S.; Jho, N.S.; Kim, M. A Key Leakage Preventive White-box Cryptographic Implementation. IACR Cryptol. ePrint Arch. 2018, 2018, 1047. [Google Scholar]
  31. Bringer, J.; Chabanne, H.; Dottax, E. Perturbing and protecting a traceable block cipher. In Communications and Multimedia Security, Proceedings of the 10th IFIP TC-6 TC-11 International Conference, Heraklion, Greece, 19–21 October 2006; Springer: Berlin/Heidelberg, Germany, 2006; pp. 109–119. [Google Scholar]
  32. Bringer, J.; Chabanne, H.; Dottax, E. White box cryptography: Another attempt. IACR Cryptol. ePrint Arch. 2006, 2006, 468. [Google Scholar]
  33. De Mulder, Y.; Wyseur, B.; Preneel, B. Cryptanalysis of a Perturbated White-Box AES Implementation. In Progress in Cryptology, Proceedings of the Conference INDOCRYPT 2010, Hyderabad, India, 12–15 December 2010; Gong, G., Gupta, K.C., Eds.; Springer: Berlin/Heidelberg, Germany, 2010; pp. 292–310. [Google Scholar] [Green Version]
  34. Karroumi, M. Protecting white-box AES with dual ciphers. In Proceedings of the International Conference on Information Security and Cryptology 2010, Seoul, Korea, 1–3 December 2010; Rhee, K.H., Nyang, D., Eds.; Springer: Berlin, Germany, 2010; pp. 278–291. [Google Scholar]
  35. Xiao, Y.; Xuejia, L. A secure implementation of white-box AES. In Proceedings of the 2009 2nd International Conference on Computer Science and Its Applications, Jeju, Korea, 10–12 December 2009; pp. 1–6. [Google Scholar]
  36. Luo, R.; Lai, X.; You, R. A new attempt of white-box AES implementation. In Proceedings of the International Conference on Security, Pattern Analysis, and Cybernetics, Wuhan, China, 18–19 October 2014; pp. 423–429. [Google Scholar]
  37. Bai, K.; Wu, C.; Zhang, Z. Protect white-box AES to resist table composition attacks. IET Inf. Secur. 2018, 12, 305–313. [Google Scholar] [CrossRef]
  38. Derbez, P.; Fouque, P.A.; Lambin, B.; Minaud, B. On Recovering Affine Encodings in White-Box Implementations. In Proceedings of the Conference on Cryptographic Hardware and Embedded Systems 2016 (CHES2016), Santa Barbara, CA, USA, 17–19 August 2016; Gierlichs, B., Poschmann, A.Y., Eds.; Springer: Heidelberg, Germany, 2016; pp. 121–149. [Google Scholar]
  39. Biryukov, A.; De Cannière, C.; Braeken, A.; Preneel, B. A toolbox for cryptanalysis: Linear and affine equivalence algorithms. In Advances in Cryptology—EUROCRYPT 2003, Proceedings of the International Conference on the Theory and Applications of Cryptographic Techniques, Warsaw, Poland, 4–8 May 2003; Springer: Berlin/Heidelberg, Germany, 2003; pp. 33–50. [Google Scholar]
  40. Dinu, I. An improved affine equivalence algorithm for random permutations. In Advances in Cryptology, Proceedings of the Conference EUROCRYPT 2018, Tel Aviv, Israel, 29 April–3 May 2018; Springer: Cham, Switzerland, 2018; pp. 413–442. [Google Scholar]
  41. Xu, T.; Wu, C.; Liu, F.; Zhao, R. Protecting white-box cryptographic implementations with obfuscated round boundaries. Sci. China Inf. Sci. 2017, 61, 039103. [Google Scholar] [CrossRef]
  42. Yongjin, Y.; Dong-Chan, K.; Hun, B.C.; Junbum, S. Cryptanalysis of the Obfuscated Round Boundary Technique for Whitebox Cryptography. Sci. China Inf. Sci. 2019. [Google Scholar] [CrossRef]
  43. Rivain, M.; Wang, J. Analysis and Improvement of Differential Computation Attacks against Internally-Encoded White-Box Implementations. IACR Trans. Cryptogr. Hardw. Embed. Syst. 2019, 2019, 225–255. [Google Scholar]
  44. Bos, J.W.; Hubain, C.; Michiels, W.; Teuwen, P. Differential computation analysis: Hiding your white-box designs is not enough. In Proceedings of the Conference on Cryptographic Hardware and Embedded Systems 2016 (CHES2016), Santa Barbara, CA, USA, 17–19 August 2016; Gierlichs, B., Poschmann, A.Y., Eds.; Springer: Heidelberg, Germany, 2016; pp. 215–236. [Google Scholar]
  45. Dusart, P.; Letourneux, G.; Vivolo, O. Differential fault analysis on AES. In Proceedings of the International Conference on Applied Cryptography and Network Security 2003, Kunming, China, 16–19 October 2003; Zhou, J., Moti, Y., Han, Y., Eds.; Springer: Berlin, Germany, 2003; pp. 293–306. [Google Scholar]
  46. Kocher, P.; Jaffe, J.; Jun, B.; Rohatgi, P. Introduction to differential power analysis. J. Cryptogr. Eng. 2011, 1, 5–27. [Google Scholar] [CrossRef] [Green Version]
  47. Alpirez Bock, E.; Bos, J.W.; Brzuska, C.; Hubain, C.; Michiels, W.; Mune, C.; Sanfelix Gonzalez, E.; Teuwen, P.; Treff, A. White-Box Cryptography: Don’t Forget About Grey Box Attacks. IACR Cryptol. ePrint Arch. 2017, 2017, 355. [Google Scholar] [CrossRef]
  48. Bock, E.A.; Brzuska, C.; Michiels, W.; Treff, A. On the ineffectiveness of internal encodings—Revisiting the DCA attack on white-box cryptography. In Proceedings of the 16th International Conference on Applied Cryptography and Network Security (ACNS2018), Leuven, Belgium, 2–4 July 2018; Preenel, B., Vercauteren, F., Eds.; Springer: Heidelberg, Germany, 2018; pp. 103–120. [Google Scholar]
  49. Biryukov, A.; Udovenko, A. Attacks and countermeasures for white-box designs. In Proceedings of the International Conference on the Theory and Application of Cryptology and Information Security, Kobe, Japan, 8–12 December 2019; Springer: Cham, Switzerland, 2019; pp. 373–402. [Google Scholar]
  50. Lee, S.; Kim, T.; Kang, Y. A masked white-box cryptographic implementation for protecting against differential computation analysis. IEEE Trans. Inf. Forensics Secur. 2018, 13, 2602–2615. [Google Scholar] [CrossRef]
  51. Banik, S.; Bogdanov, A.; Isobe, T.; Jepsen, M. Analysis of software countermeasures for whitebox encryption. IACR Trans. Symmetric Cryptol. 2017, 2017, 307–328. [Google Scholar]
  52. Marin, L. White Box Implementations Using Non-Commutative Cryptography. Sensors 2019, 19, 1122. [Google Scholar] [CrossRef] [PubMed]
  53. Bogdanov, A.; Rivain, M.; Vejre, P.S.; Wang, J. Higher-order DCA against standard side-channel countermeasures. IACR Cryptol. ePrint Arch. 2018, 2018, 869. [Google Scholar]
  54. Fouque, P.A.; Karpman, P.; Kirchner, P.; Minaud, B. Efficient and provable white-box primitives. In Advances in Cryptology, Proceedings of the ASIACRYPT 2016, Hanoi, Vietnam, 4–8 December 2016; Cheon, J.H., Takagi, T., Eds.; Springer: Berlin/Heidelberg, Germany, 2016; pp. 159–188. [Google Scholar]
  55. Biryukov, A.; Perrin, L. Symmetrically and Asymmetrically Hard Cryptography. In Proceedings of the International Conference on the Theory and Application of Cryptology and Information Security, Hong Kong, China, 3–7 December 2017; Springer: Cham, Switzerland, 2017; pp. 417–445. [Google Scholar] [Green Version]
  56. Bock, E.A.; Amadori, A.; Bos, J.W.; Brzuska, C.; Michiels, W. Doubly half-injective PRGs for incompressible white-box cryptography. In Proceedings of the Cryptographers’ Track at the RSA Conference, San Francisco, CA, USA, 4–8 March 2019; Springer: Cham, Switzerland, 2019; pp. 189–209. [Google Scholar]
  57. Feng, Q.; He, D.; Wang, H.; Kumar, N.; Choo, K.K.R. White-Box Implementation of Shamir’s Identity-Based Signature Scheme. IEEE Syst. J. 2019. [Google Scholar] [CrossRef]
  58. Goubin, L.; Paillier, P.; Rivain, M.; Wang, J. How to reveal the secrets of an obscure white-box implementation. J. Cryptogr. Eng. 2018. [Google Scholar] [CrossRef]
  59. Moriarty, K.; Kaliski, B.; Rusch, A. PKCS# 5: Password-Based Cryptography Specification Version 2.1. Internet Requests for Comments. RFC 8018 2017. Available online: https://tools.ietf.org/html/rfc8018 (accessed on 3 June 2019).
  60. Visconti, A.; Bossi, S.; Ragab, H.; Calò, A. On the weaknesses of PBKDF2. In Cryptology and Network Security, Proceedings of the 14th International Conference, CANS 2015, Marrakesh, Morocco, 10–12 December 2015; Reiter, M., Naccache, D., Eds.; Springer International Publishing: Cham, Switzerland, 2015; pp. 119–126. [Google Scholar]
  61. Visconti, A.; Mosnáček, O.; Brož, M.; Matyáš, V. Examining PBKDF2 security margin—Case study of LUKS. J. Inf. Secur. Appl. 2019, 46, 296–306. [Google Scholar] [CrossRef]
  62. Visconti, A.; Gorla, F. Exploiting an HMAC-SHA-1 optimization to speed up PBKDF2. IEEE Trans. Dependable Secur. Comput. 2018. [Google Scholar] [CrossRef]
  63. Biryukov, A.; Dinu, D.; Khovratovich, D. Argon2 (Version 1.2). 2018. Available online: https://password-hashing.net/submissions/specs/Argon-v3.pdf (accessed on 28 May 2019).
  64. Percival, C.; Josefsson, S. The scrypt Password-Based Key Derivation Function. Internet Requests for Comments. RFC 7914. 2016. Available online: https://tools.ietf.org/html/rfc7914 (accessed on 30 May 2019).
  65. Banks, A.; Gupta, R. MQTT Version 3.1.1 Plus Errata 01. Available online: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html (accessed on 24 May 2019).
  66. Light, R.A. Mosquitto: Server and client implementation of the MQTT protocol. J. Open Source Softw. 2017, 2, 265. [Google Scholar] [CrossRef]
Figure 1. Table-based white-box implementation: the key k is scrambled by a network of lookup tables.
Figure 1. Table-based white-box implementation: the key k is scrambled by a network of lookup tables.
Symmetry 11 01000 g001
Figure 2. The value of each image of F n a ( x ) is saved as a row in a look-up table. Every row is indexed by the value of x, x { 0 , , 2 n a 1 } .
Figure 2. The value of each image of F n a ( x ) is saved as a row in a look-up table. Every row is indexed by the value of x, x { 0 , , 2 n a 1 } .
Symmetry 11 01000 g002
Figure 3. A black-box implementation (server-side).
Figure 3. A black-box implementation (server-side).
Symmetry 11 01000 g003
Figure 4. A BitShift key-dependent: increasing the size of the round key from 8 to 11 bits.
Figure 4. A BitShift key-dependent: increasing the size of the round key from 8 to 11 bits.
Symmetry 11 01000 g004
Figure 5. Substitution–permutation network (SPN)box: a new inner round γ .
Figure 5. Substitution–permutation network (SPN)box: a new inner round γ .
Symmetry 11 01000 g005
Table 1. Results of tests on i3-330M with Ubuntu 18.04.1 LTS 64-bit.
Table 1. Results of tests on i3-330M with Ubuntu 18.04.1 LTS 64-bit.
γ γ with BitShift
n i n = 32, encryption1.178316 s0.955048 s
n i n = 32, decryption1.447580 s1.168507 s
n i n = 16, encryption3.946748 s3.222751 s
n i n = 16, decryption4.193261 s3.308678 s
n i n = 8, encryption2.547156 s2.192452 s
n i n = 8, decryption2.564750 s2.250102 s
Table 2. Results of tests on i3-350M with Ubuntu 18.04.2 LTS 64-bit.
Table 2. Results of tests on i3-350M with Ubuntu 18.04.2 LTS 64-bit.
γ γ with BitShift
n i n = 32, encryption1.116117 s0.902140 s
n i n = 32, decryption1.367435 s1.150235 s
n i n = 16, encryption3.717744 s3.035942 s
n i n = 16, decryption3.954781 s3.116000 s
n i n = 8, encryption2.395998 s2.061877 s
n i n = 8, decryption2.405397 s2.114405 s
Table 3. Results of tests on i7-2860QM with Kubuntu 18.10 64-bit.
Table 3. Results of tests on i7-2860QM with Kubuntu 18.10 64-bit.
γ γ with BitShift
n i n = 32, encryption0.837671 s0.668838 s
n i n = 32, decryption0.925293 s0.816856 s
n i n = 16, encryption2.667934 s2.147471 s
n i n = 16, decryption2.811657 s2.394600 s
n i n = 8, encryption1.886357 s1.565764 s
n i n = 8, decryption2.030491 s1.777118 s
Table 4. Results of tests on i7-5500U with Ubuntu 18.04.2 LTS 64-bit.
Table 4. Results of tests on i7-5500U with Ubuntu 18.04.2 LTS 64-bit.
γ γ with BitShift
n i n = 32, encryption0.861415 s0.701899 s
n i n = 32, decryption0.954985 s0.782088 s
n i n = 16, encryption2.980274 s2.461575 s
n i n = 16, decryption3.155612 s2.543056 s
n i n = 8, encryption1.860916 s1.774127 s
n i n = 8, decryption1.879749 s1.785562 s
Table 5. Results of tests on i7-8550U with Ubuntu 18.04.2 LTS 64-bit.
Table 5. Results of tests on i7-8550U with Ubuntu 18.04.2 LTS 64-bit.
γ γ with BitShift
n i n = 32, encryption0.681576 s0.526522 s
n i n = 32, decryption0.723118 s0.587942 s
n i n = 16, encryption2.396308 s1.898987 s
n i n = 16, decryption2.462049 s1.933232 s
n i n = 8, encryption1.160104 s1.258072 s
n i n = 8, decryption1.179036 s1.248327 s
Table 6. Results of tests on i3-350M with Debian GNU/Linux 9 32-bit.
Table 6. Results of tests on i3-350M with Debian GNU/Linux 9 32-bit.
γ γ with BitShift
n i n = 32, encryption1.247818 s1.041543 s
n i n = 32, decryption1.967226 s1.558086 s
n i n = 16, encryption3.721377 s3.381363 s
n i n = 16, decryption4.164744 s3.262065 s
n i n = 8, encryption2.399780 s2.065451 s
n i n = 8, decryption2.412146 s2.127425 s
Table 7. Encryption/decryption operations with a black-box implementation (server-side).
Table 7. Encryption/decryption operations with a black-box implementation (server-side).
Payload n in EncryptionDecryption
(Bytes)(Bits)w/o BitShiftwith BitShiftGainw/o BitShiftwith BitShiftGain
323.668 s3.319 s9.507%0.893s0.741s16.999%
16166.335 s5.763 s9.037%3.096s2.412s22.091%
84.510 s4.882 s−8.254%1.479s1.551s−4.929%
326.679 s5.601 s16.139%3.636s2.950 s18.865%
641614.869 s12.362 s16.860%12.488 s10.023 s19.739%
88.817 s9.616 s−9.060%6.183s6.446 s−4.253%
3216.021 s13.847 s13.569%14.166 s11.827 s16.512%
1281651.098 s38.998 s23.680%50.632 s39.596 s21.798%
824.280 s25.709 s−5.884%24.454 s25.825 s−5.607%
3254.047 s41.716 s22.816%56.494 s47.065 s16.690%
102416191.262 s151.101 s20.998%195.424 s154.029 s21.182%
892.651 s98.998 s−6.850%93.744 s98.362 s−4.926%

Share and Cite

MDPI and ACS Style

Albricci, D.G.V.; Ceria, M.; Cioschi, F.; Fornari, N.; Shakiba, A.; Visconti, A. Measuring Performances of a White-Box Approach in the IoT Context. Symmetry 2019, 11, 1000. https://doi.org/10.3390/sym11081000

AMA Style

Albricci DGV, Ceria M, Cioschi F, Fornari N, Shakiba A, Visconti A. Measuring Performances of a White-Box Approach in the IoT Context. Symmetry. 2019; 11(8):1000. https://doi.org/10.3390/sym11081000

Chicago/Turabian Style

Albricci, Daniele Giacomo Vittorio, Michela Ceria, Federico Cioschi, Nicolò Fornari, Arvin Shakiba, and Andrea Visconti. 2019. "Measuring Performances of a White-Box Approach in the IoT Context" Symmetry 11, no. 8: 1000. https://doi.org/10.3390/sym11081000

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop