Keywords

1 Introduction

Many Internet-of-Things (IoT) applications have lately been using the technique of Quick Response Code (QR-Code) to allow many smart services and tasks be done in a very short period of time [1,2,3]. The number of researches [4,5,6,7,8] focusing on the use of QR-Code is gradually increasing [9, 10]. Such researches produce smart services to the user whereas private data are used. Thus, there is a continuous need to protect data from being used by an unauthorized party.

Usually, Many IoT-based applications have become widely used to do many smart services and tasks which require a sufficient and precise process in a short period of time. Thus, a lot of information, caused by the huge portion of data being stored, requires fast processing.

The QR-Code is a very effective tool and has been used by many applications to with different purposes. Usually, QR tags store data in an encrypted form where scanners are used to extract data. Then, depending on the system or application the QR-Code is used for, a verification procedure follows the extraction step to make sure those extracted values are identical to original values before being encrypted [11].

Hence, various factors are taken into account when such a smart application is designed e.g., privacy, authentication, availability, data integrity, data recovery, responsiveness, reliability … etc. Depending on the kind of the smart application being used for, certain security factors rise up to make that application as perfect as possible, more than other factors do. Smart home applications, for example, require privacy, safety, and responsiveness …etc. Embedded systems such as health systems require more responsiveness and reliability. Sensor based collection systems reliability and maintainability. Hence, there is a need to consider all above mentioned security factors using a strong encryption scheme to include as many factors as it could.

Proposed works in [12, 13] have designed two different methods to generate a QR-Code. In [12], a graphical design has been used to make sure that documents being verified are secure whereas the document authentication factor has been considered. The design in [13] has considered both privacy and usability factors by using array of patterns that includes no much details. Similarly, another proposed QR-Code design [14] to protect private data, a print-and-scan (P&S) operation has been addressed whereas the data privacy factor has been investigated. Additionally, QR-Code designs have been used with root applications. In order to measure distances accurately and reliably, landmark images and image recognition processes have been used to head the robot to estimate the accurate location detection [15].

On the other hand, smart and IoT applications have numerous uses reviewed in literature. Some researches, for example, have proposed a security purposed method for smart home [16], monitoring purposed application [17], biometrics-based home access system [18], embedded physical evaluation method [19] … etc. These IoT applications require, for example, reliable responsiveness, security, and authentication. IoT technology relies on some other essential tools to successfully and accurately build such a system. One of these tools is the encryption scheme by which the smart system is robust. The verification procedure is however another important tool for a robust smart application. Usually, the encryption scheme needs to be followed by a strong verification procedure. Therefore, any the encryption scheme is so essential for smart and IoT applications because it affects the whole smart system including the verification procedure as well.

In general, proposed methods have utilized the security and privacy of contents however the computation time and code complexity are still of importance to be considered by many IoT applications.

This paper focuses on designing a different way of encryption for both plaintext and secret key. It proposes an Algebraic Operations-based Secret Key Design for Encryption Algorithm (ASKEA) focuses on the authentication and integrity. ASKEA is used to increase privacy of several information-centric applications such as energy informatics, IoT, and smart home applications. In this work, QR-Code has been acted as a landmark image to ease the recognition process considering both reliability and responsiveness factors to attain integrity and availability. To protect data stored in a QR-Code which is used with IoT based smart applications, this paper proposes an unpredictable secret key design by which the QR-Code tag is encrypted.

ASKEA has used a strong encryption procedure in order to increase the time needed to decrypt the QR-Code information in case the secret key has been deduced. ASKEA however has focused to use a 1-session secret key policy with the most of encryption steps so that encrypted data will not be decrypted; this is to increase the privacy and secrecy of the user’s information. In order to attain the availability, the encryption policy generates a random unpredictable key. Furthermore, the proposed design has considered a very long encryption key to reduce the vulnerability of being deduced; it takes very long time to attack and crack the key. So that data integrity could be achieved.

This paper is organized as follows: Sect. 2 is dedicated to explain the schematic representation for ASKEA. Section 3 is dedicated for Results and Discussion. Conclusion has been drawn in Sect. 4.

2 The Proposed ASKEA Schematic Representation

The proposed ASKEA is relevant to user information encryption. Its encryption scheme deals with the way the collected information is being protected. ASKEA is proposed to protect information from being modified in an unauthorized manner. This paper aims to design the secret key based on the ASKEA plaintext. A generalized schematic representation is shown in Fig. 1 to show ASKEA main steps and its relationship with such a verification tool.

Fig. 1.
figure 1

A generalized ASKEA schematic representation

Full size image

In Fig. 1, information will be encrypted and stored. Then, the QR-Code is generated based on the encrypted values. Then, the user interface starts. Once, an access is needed by the user, the ASKEA immediately is called to enable the verification. However, the encryption process is called two times; the first one, when it is used to encrypt original information collected from the user at the first time. Another call happens when there is a need to update the database with new values, such as SQ values, new hash values …etc. One of the main uses for ASKEA, as marked in Fig. 1 with numerical labels: 5 and 6, is to be used as a verification tool for a number of IoT applications using QR-Code.

2.1 The Proposed ASKEA Design

This section is dedicated to explain the ASKEA basic design and how this proposed design could be used with a verification tool for energy informatics related applications.

2.2 Proposed ASKEA Inputs’ Design

Initially, ASKEA encrypts whole information collected from the user. Information includes certain values that consist of pure characters, numbers, and a mixture of characters and numbers as described in Fig. 2.

Fig. 2.
figure 2

User’s information category

Full size image

In Fig. 2, data types of ‘character’, ‘number’, and ‘character/ number’ are assigned to be stored in the ‘name’, ‘phone no., fax …etc.’, ‘address, website, email …etc.’ fields, respectively.

To increase the security of encryption scheme, further matter has been considered that is a variable with a property that is capable to frequently change its value and data type. Usually, the user has different activities. Thus, the user could be asked to answer a security question. This feature is so useful to create different answers with different values producing amounts by which the field can be increased or decreased in case the answer is a number. As expected, in case the SQ answer alters, for example, from text to number, its data type will be changing accordingly. This proposed scheme is illustrated in Fig. 3.

Fig. 3.
figure 3

Proposed user’s information category for ASKEA

Full size image

Unlike values of fields, shown in Fig. 2, are constants and related data types are fixed; the field in Fig. 3 is dynamically and periodically changing in value and data type. This has added a feature that is, the value is difficult to be predicted when a threat is trying to access or modify data contents.

As can be seen in Fig. 3, there will be two attributes considered as inputs for ASKEA which are: User SQ (USQ), and User ID (UID). Description of fields of which ASKEA inputs consist is provided in Table 1.

Table 1. Description of input items of ASKEA
Full size table

As can be seen in this table, the field of ‘User SQ (USQ)’ has the following data description: a Data_Type = ‘number, character or symbol’, Array_Size = ‘1D’, Status_of_Data_Type can alter between ‘numbers’, ‘characters’, and ‘symbols’, and Field_Value = ‘variable’.

2.3 Proposed ASKEA Secret-Key Length Design

In order to implement the ASKEA, a series of cascade encryption processes are applied on fields related values. The output of ASKEA is the QR-Code for User ID, User SQ. The technical procedures will be discussed in this section.

ASKEA has adopted to use two schemes for key length, which are \(2^{i}\) and \(2^{i} + 2^{i - 1}\). However, the value of i is designed to be adjustable between key length and encrypted data size. The increment denoted by \(2^{i - 1}\) for the second key length is to take into account any increment caused by a potential change inside the ‘field value’ or ‘data type’. Referring to Table 1, for example, the SQ increment could probably happen when it is increased or altered between numbers and characters. However, this design includes a limitation relates to the maximum length of the secret key by the value \(2^{i} + 2^{i - 1}\). Thus, the key length must be greater than or equal to the data size.

Therefore, the following two formulas are considered for the secret key length, shown in Eq. (1) and Eq. (2):

$$ 2^{i} \le key_{1} \,\,length $$
(1)
$$ key_{2} \,\,length \ge 2^{i} + 2^{i - 1} $$
(2)

2.4 Mathematical Design of ASKEA Input (Plaintext)

The key length has a directly proportional relationship with user information being encrypted. That is, and from this information, the encryption scheme is going to extract a certain amount of data (i.e., plaintext) to be encrypted; and not whole user’s information. This amount of data (plaintext) being encrypted is, as mentioned before, mutable due to it depends on alteration of data type(s). As a result, this amount of data is considered as an ASKEA plaintext input whereas it has a variable length producing two different sizes in bits/ Bytes. The design of key length has considered both minimum and maximum sizes of the plaintext input. This criterion is a must and is expressed in inequalities (1) and (2):

$$ u_{{data_{min} }} < 2^{i} $$
(3)
$$ u_{{data_{max} }} < 2^{i} + 2^{i - 1} $$
(4)

whereas \(u_{{data_{min} }}\) and \(u_{{data_{max} }}\) minimum and maximum size(s) of data entered by the user, respectively.

Thus, in order to derive the relationship between the key length and data size with consideration of the adjustable variable (i): firstly, inequalities (2) and (4) are used to produce inequality (6); secondly, inequalities (3) and (5) are used to produce inequality (7), as follows:

$$ u_{{data_{min} }} < 2^{i} \le { }key_{1} \,\,length $$
(5)
$$ u_{{data_{max} }} < 2^{i} + 2^{i - 1} \le { }key_{2} \,\,length $$
(6)

Thus, inequalities (6) and (7) could produce the following expression:

$$ size\,\,of\,\,data < adjustable\,\,variable \le { }key\,\,length $$
(7)

2.5 Proposed Mathematical Operations Based ASKEA Design

As discussed, there is a proportional relationship between the secret key size and data size with consideration of adjustable variable, therefore these two mathematical formulas are true:

$$ f\left( {key} \right) \propto f\left( {data} \right) $$
(8)
$$ f\left( {key} \right) = f\left( {data} \right) + c_{HEA} $$
(9)

where,

  • \(f\left( {data} \right)\) is an independent function to which user’s information is assigned

  • \(f\left( {key} \right)\) is a dependent function and varies based on \(f\left( {data} \right)\)

  • \(c_{HEA}\) is an ASKEA constant designed exclusively to normalize the size of \(f\left( {data} \right)\) to a fixed size that is proportional to the length of \(f\left( {key} \right)\)

This equation relates mainly to the length of secret key and size of data being encrypted. Meaning, Eq. (9) is mathematically represented as in Eq. (10):

$$ size_{{f\left( {key} \right)}} = size_{{f\left( {data} \right)}} + \mathop {size_{c} }\nolimits_{HEA} $$
(10)

where,

  • \(size_{{f\left( {key} \right)}}\) is the function by which the key size is calculated

  • \(size_{{f\left( {data} \right)}}\) is the function used to store a piece of data extracted from user’s information; data to be sent to ASKEA for encryption purpose

  • \(size_{{c_{HEA} }}\) calculates the size of \(c_{HEA}\) by which the plaintext size is normalized to the key length

Equation (10) could be mathematically re-formulated as:

$$ k_{size} = P_{{text_{size} }} + c_{{HEA_{size} }} $$
(11)

where,

  • \(k_{size}\) has two secret key sizes which are represented in Eq. (12):

    $$ k_{size} = \left\{ {\begin{array}{*{20}l} {2^{i} } \hfill & {f\left( {data} \right) = minimum\,\,size\,\,of\,\,data} \hfill \\ {2^{i} + 2^{i - 1} } \hfill & {f\left( {data} \right) = maximum\,\,size\,\,of\,\,data} \hfill \\ \end{array} } \right\} $$
    (12)

  • \(P_{{text_{size} }}\) is an aggregation function relates to data entered by user, refer to Table 1, as mathematically represented in Eq. (13):

    $$ P_{{text_{size} }} = f\left( {input_{user} } \right) $$
    (13)

  • \(c_{{HEA_{size} }}\) is an ASKEA constant and can be calculated using Eq. (14) producing two different values based on minimum and maximum size of data entered by the user:

    $$ c_{{HEA_{size} }} = \left\{ {\begin{array}{*{20}l} {2^{i} - P_{{text_{size} }} } \hfill & {2^{i} \ge u\_data_{min} } \hfill \\ {2^{i} + 2^{i - 1} - P_{{text_{size} }} } \hfill & {2^{i} < u\_data_{max} } \hfill \\ \end{array} } \right\} $$
    (14)

2.6 \({\varvec{P}}_{{{\varvec{text}}_{{{\varvec{size}}}} }}\) Design

In this subsection, ASKEA inputs are in detail discussed. That aims to explain how to obtain appropriate values for length and sizes of ASKEA inputs. Following considerations are in detail discussed:

As for data entered by user, it is a function in which whole entered information is aggregated, see Eq. (13). Once the user has entered and filled up required fields, a series of algebraic operations extracts a piece of data from user’s information in accordance with ‘ASKEA Input Field’ mentioned in Table 1. It is an aggregation function of several user inputs whereas it is simply formulated in (15):

$$ f\left( {P_{text} } \right) = f\left( {{ }USQ,{ }UID} \right) $$
(15)

where,

  • \(f\left( {P_{text} } \right)\) represents assigned data to ASKEA as a plaintext

  • \(f\left( {{ }USQ,{ }UID} \right)\) represents data-required input-fields (DRIFs).

In order to determine the size specified for each function, a size-purposed algebraic function has been proposed to obtain the bits-length needed (BLN) for each DRIF. To calculate BLN for each DRIF, a certain piece-of-data (PoD) is extracted from the related DRIF based on algebraic operations and then PoD’s size is passed to the BLN.

Thus, to ease the procedure mentioned in Eq. (15), each BLN could be calculated for every DRIF using the following mathematical formulas shown in Eq. (16) and Eq. (17):

$$ f\left( {USQ} \right) = inp\left( {u_{SQ} } \right) $$
(16)
$$ f\left( {UID} \right) = inp\left( {u_{ID} } \right) $$
(17)

where,

  • \(f\left( {USQ} \right)\), and \(f\left( {UID} \right)\) are DRIFs for user SQ and user ID, respectively

  • \(inp\left( {u_{SQ} } \right)\) and \(inp\left( {u_{ID} } \right)\) are alphanumeric values of PoD for USQ and UID RFIDs, respectively.

Once \(inp\left( {u_{SQ} } \right)\) and \(inp\left( {u_{ID} } \right)\) have been calculated, the \(P_{text}\) is ready to feed the ASKEA, using Eq. (18). In order to find the appropriate ASKEA secret key size, BLNs need to be firstly calculated for each DRIF by using Eqs. (19) - (20):

$$ f\left( {P_{text} } \right) = inp\left( {u_{SQ} } \right) + inp\left( {u_{ID} } \right) $$
(18)
$$ BLN_{USQ} = size_{bits} \left\{ {inp\left( {u_{SQ} } \right)} \right\} $$
(19)
$$ BLN_{UID} = size_{bits} \left\{ {inp\left( {u_{ID} } \right)} \right\} $$
(20)

By obtaining values of BLNs in Eqs. (19) - (20), Eq. (13) is re-formulated as in Eq. (21):

$$ \mathop {P_{text} }\nolimits_{size} = BLN_{USQ} + BLN_{UID} $$
(21)

Usually, a PoD for each DRIF consists of a number of alphanumeric/ numeric values. Thus, each PoD has a ‘value’ and ‘data type’. The relation between PoD and DRIF items is provided in Table 2.

Table 2. DRIF and PoD
Full size table

As mentioned before in Table 1, fields requiring data entries whether by automatically or manually ways are supersets of ASKEA inputs. Thus, a series of mathematical subsets which can be derived from Table 2 are mathematically represented, as follows: \(\left\{ {DRIFs} \right\} \subset \left\{ {HEA\,\,Input\,\,Attributes} \right\}\), the set DRIF is represented by Eq. (22):

$$ \left\{ {DRIF} \right\} = \left\{ {\left\{ {USQ} \right\},\left\{ {UID} \right\}} \right\} $$
(22)

Each subset is defined using the following algebraic description:

$$ \left\{ {USQ} \right\} = \{ inp_{SQ} :\forall inp \in \,user\, inputs\,for\,SQ\}_{ } $$
$$ \left\{ {UID} \right\} = \{ inp_{ID} :\forall inp \in \,user\,inputs\,for\,ID\} $$

Each PoD is a subset of its related DRIF’s superset, which is mathematically represented as follows: \(\left\{ {PoDs} \right\} \subset \left\{ {DRIFs} \right\}\).

As a result, further defined descriptions could be derived, as follows:

$$ \left\{ {PoD_{USQ} } \right\} \subset \left\{ {USQ} \right\};\,\, \Leftrightarrow \left\{ {PoD_{USQ} } \right\} \cap \left\{ {USQ} \right\} = \left\{ {PoD_{USQ} } \right\} $$
$$ \left\{ {PoD_{UID} } \right\} \subset \left\{ {UID} \right\};\,\, \Leftrightarrow \left\{ {PoD_{UID} } \right\} \cap \left\{ {UID} \right\} = \left\{ {PoD_{UID} } \right\} $$

Each of abovementioned algebraic definitions is true with every condition accompanied.

As per the design limitation, the user is allowed to enter an answer for the SQ with a length up to 8 Bytes.

In this design, the minimum size of an answer the user can type is ‘1’ alphanumeric e.g., ‘1’, ‘#’, ‘a’, or ‘z’. Thus, ‘1’ alphanumeric can be written as: \(2^{b}\); whereas \(b = 3\).

Therefore, 1 Byte is a minimum length of the SQ answer. As a result, the proposed algorithm has adopted that 1 character of 8-bits length is assigned to ‘\(i\)‘. That is represented in by Eq. (23):

$$ i = 2^{b} $$
(23)

2.7 Proposed ASKEA Block-Diagram Design

A simple model of ASKEA ingredients for two schemes of plaintext size(s), which are \(P_{{text_{size} }} < 2^{i}\) and \(P_{{text_{size} }} < 2^{i} + 2^{i - 1}\), is illustrated in Fig. 4.

Fig. 4.
figure 4

ASKEA block-diagram – security scheme design

Full size image

3 Results and Discussion

This part presents results in terms of plaintext time complexity, computation time, security factors. Then, it evaluates the proposed design performance based on abovementioned obtained results.

3.1 Time Complexity

Big-O-Notation will be used for a further evaluation and comparative analysis. The running time for the proposed secret key design will be described. Two main procedures will be evaluated which are plaintext entries values and secret key variables. Usually, O(n) with the proposed design depends on user entries and values being extracted.

As for USQ and UID, O(n) depends on values being generated from equations. An array \(A_{USQ} \left[ {k1} \right]\) and \(A_{UID} \left[ {k2} \right]\) is dedicated to store k elements. Therefore: O(n) for this case is defined as in Eqs. (24) and (25):

$$ O\left( n \right)_{{{\text{A}}_{{{\text{USQ}}}} \left[ {k1} \right]}} = O\left( {k1} \right) $$
(24)
$$ O\left( n \right)_{{{\text{A}}_{{{\text{UID}}}} \left[ {k2} \right]}} = O\left( {k2} \right) $$
(25)

Totally, \(O\left( n \right)\) for ASKEA is a summation formula of Eqs. (24) and (25). Since \(k1\) and \(k2\) are constants, therefore Eq. (26) is used to obtain value of \(O\left( n \right)_{{{\text{ASKEA}}}}\):

$$ O\left( n \right)_{{{\text{ASKEA}}}} = O\left( k \right) $$
(26)

A time complexity value equals to \(O\left( k \right)\) looks reasonable when compared to other time complexity schemes.

3.2 Time Based Efficiency

The proposed design scheme of secret key design in term of computation time needed to generate one secret key. The proposed ASKEA in term of secret key and plaintext processing computation times has been compared to other methods which are Password and Certificate techniques. The obtained result is given in Fig. 5.

In this comparison, the procedure of how samples are taken is explained as follows: many tests using different samples of entries have been considered. There have been seven tests at which different number of samples is considered. In regard to the proposed design, the user entries of plaintext have been fed to the ASKEA inputs which are \(P_{{text_{size} }}\) and \(k_{size}\). For the first implemented test, 7 samples are considered to produce 7 secret keys accordingly. The computation time for each sample is recorded; whereas the computation time mentioned in Fig. 5 is the average computation time for whole samples of the related test. Similarly, this is repeated for the rest of tests with different number of samples. As for Password and Certificate techniques, both are used to create the same number of words.

Fig. 5.
figure 5

Average computation times of the proposed secret key design vs. others

Full size image

There are seven tests in which 10, 20, 50, 75, 100, 200, and 500 samples have been considered. Thus, the computation time for each sample is calculated and then the average computation time is obtained for whole samples for every test. The related result is provided as mentioned in Fig. 5.

As noticeable, the proposed design has less time than Certificate and Password techniques unless two tests in case of Password. The reason is that the length of secret key is the maximum length which is considered acceptable when comparing to the Certificate technique.

3.3 Security Factors Analysis - Confidentiality and Privacy vs. Unpredictability

The aim of choosing 2 schemes of key length is to increase the privacy of encryption algorithm by building an unpredictable behavior of key. Thus, the way the secret key changes help increase the confidentiality of plaintext being encrypted.

4 Conclusion

This paper has proposed a dynamical design for a secret key based on user plaintexts. Original inputs are encoded. To perform such a design, a number of algebraic operations have been derived and proposed. The essential part in designing such a secret key is to keep an unpredictable behavior of ASKEA in terms of key length and the way the values are generated. This design could be followed by a verification tool in which a QR-Code is used to achieve a high level of security and privacy to such energy informatics, smart home, and EIoT applications.