4.3 Performance of The Proposed Method 3: Tranformation and Matching Strategy for Iris Code
4.3.3 Security Analysis: Non-Invertibility
The non-invertibility of the proposed scheme can be achieved by the one- way hashed of the transformed template (π, πβ²). The usage of cryptographic one- way hashing in this scheme is an unorthodox manner instead. Specifically, the matching between the transformed templates is done by counting the number of non-collided entries in between the pair-wise (columns) transformed template (after one-way hashed). Only the column of the enrolled and query templates that show at most π non-collided entries, i.e., βππβ ππβ²β β€ π, will contribute to the count (π§) for the final similarity matching score. This is to assert a strong prerequisite for the attacker in reverting the original iris code, where the attacker is required to look for the pre-image of the hashed entry that consists of π bits in order to revert the original iris code. For instance, given an original entry of the transform template x = 7 (where π = 3), its corresponding binary value would be 111, which indicates different bit locations of the original iris code.
Since x is one-way hashed, i.e., hash(x), the attacker would have to look for a pre-image xβ² s.t. hash(xβ²) = hash(x). Given xβ², reverting π = 3 bits information of the original iris code thus can be done trivially by βreverse permutationβ using the published bit-sampling functions.
In view of above, for an arbitrary key length π, the non-invertibility of our proposed scheme reduced to the computational hardness in looking for a preimage of the one-way hash function. Nevertheless, due to the dimensional compatibility requirement, i.e., the key length must same for each transformed templates, which is necessary for template matching; The number of trials in looking for a preimages of the one-way hashed function must be bounded by
O(2π). Therefore, large π is necessary to show strong non-invertibility claim of this proposed scheme.
Besides from this, consider that the attacker is capable of pre-computing a hash table for all possible 2π entries of the transformed template, we proposed to use a random salt that is used as an additional input to a one-way function such as md5 or AES encryption. Using additional random salt can defend against attacks that use precomputed tables for e.g. rainbow tables (Hellman, 1980) as they can make the size of table needed for a successful attack prohibitively large without burdening users. Since salts differ from one another, they also protect redundant (e.g. commonly-used, re-used) passwords as different salted hashes are created for different instances of the same transformed entries(Anderson, 2020).
For different system/application, a new salt can be randomly generated for each transformed template, and fed together with the template entries to a one-way cryptographic hash function. Noting that the salt don't need to be encrypted or stored separately from the hashed password itself, because even if an attacker has access to the database with the hash values and the salts, a pre- image xβ² is still necessary to obtain any bit information of the original iris code.
This has been assured by the non-invertibility of our proposed transformation.
Correlation in between iris codes: Because the distribution of a biometric source
is random and not necessary to be uniformly distributed. Two Iris codes generated from different users may show some degree of similarity by correlation. One example as shown in Figure 3.16 (a) demonstrated that when
ππ = 1, it is hard to distinguish whether the query iris code (column) is belonged to the genuine user or imposter. This result implies that the attacker is capable of making use of the vertical dependency property in iris codes and try to revert the original iris code while intercept with the transformed template. A straightforward way of doing this is by sampling a random iris code and follows the proposed transformation and matching mechanism. Since hashing leaks information, the attacker can look for any collided entries in between the stored and query template. Then, perform a reverse engineering process to recovery the original iris code. In such a case, the non-invertibility of the proposed scheme can be examined upon the capability of the attacker to sample an iris code that shows at least one collided entries with the stored template when taking into consideration the correlation in between iris codes. To show the resistance of a scheme against this kind of attack, one needs to ensure that, in average-case, the attacker cannot obtain a single or more than one collided entries by random sampling on an iris code. In view of this, reducing the number of hash entries (reduce information loss) of the stored template would be necessary to achieve strong non-invertibility property against different correlated iris codes.
In the favour of reducing the number of hash entries, the parameters π is meant to be minimized. Table 4.14 below tabulates the performance (EER, %) of the proposed scheme with different parameter settings for π ranging from 10 to 40 with constant π = π β 1 and ππ = 1. This result shows that minimizing π will lead to performance degradation (while π and ππ are fixed), resulting a trade-off in between non-invertibility and system performance.
Table 4.14: Trade-off between non-invertibility and system performance
Performance EER,%
r = 10 r = 15 r = 20 r = 25 r = 30 r = 35 r = 40
Proposed Method 0.92 0.87 0.83 0.66 055 0.53 0.48
Besides, Figures 4.7 depicts the average number of collided entries for individual columns of the transformed templates (1 to 512). It is clearly observable that the transformed templates show several peaks due to the number of the collided entries under different columns. Such peaks indicate the columns of the iris codes that exhibit strong correlation. Such correlation can be minimized using smaller value of π which render, in average, less than single collided entries over the one-way hashed template to resist against the abovementioned attack.
Figure 4.7: Correlation Between Different One-way Hashed Templates