Comparison Methodology

To compare the storage requirements, the naive approach as well as both (t, n)-threshold verification variants are evaluated at PIN-level and password-level security. The example configurations described in section 7.3 are used as basis for this storage evaluation.

To explore the properties of the (t, n)-threshold verification variants beyond these two security levels, results for six additional configurations are provided. These additional configurations are based on random strings over the broadly considered alphabet of the 95 characters on a standard US keyboard (see e.g. [100]). The recommended key lengths for high security cryptographic keys given by Eastlake et al. [63] serve as upper bound in terms of password strength. At the time of writing appropriate key lengths are in the 86 to 106 bit range. The parameter p for these configurations is chosen as the largest prime representable with the same number of bytes as the minimum value for p as determined by equation (7.5).

Barker et al. provide recommendations in terms of key length and respective hash functions [17]. At the time of writing SHA-256 and AES-128 are adequate choices. Thus, salted SHA-256 (hash size 32 bytes) is considered as hashing algorithm and AES-128 as symmetric encryption throughout the whole evaluation. Salted SHA-256 hashing is used as KDF for both, the naive and the (t, n)-threshold verification scheme. Following the recommendations of Moriarty et al. [147] the salt was chosen to be 64 bit. Therefore, the size of the hashes and salts is bhash= 40 bytes for both (t, n)-threshold verification variants as well as the naive approach.

7 The (t,n)-threshold Verification Scheme for Portfolio Authentication

Figure 7.6: The storage requirements of the naive approach and the two (t, n)-threshold verification scheme variants in bytes. Lower values are better.

7.4.5 Comparison Results

In the following, the storage at the aforementioned security levels is described. The PIN-level and the password-level are described in detail (for a summary of the results see figure 7.6). The levels beyond these two are summarised.

PIN-level

Using equation (7.6) with settings for the PIN-level, the overall storage requirement for the naive approach is bnaive=   6 4  · 40 bytes= 600 bytes.

For the two (t, n)-threshold verification variants, the storage requirements in the PIN-level setting are: bBlakley= 6 · 4 · 2 bytes + 40 bytes = 88 bytes

bShamir= (6 + 1) · 16 bytes + 40 bytes = 152 bytes

It becomes apparent that the variant based on Blakley secret sharing is the most efficient option at the PIN-level.

Password-level

On the password level, the storage requirements of the naive approach as well as the two (t, n)-threshold verification variants are:

bnaive=   8 5  · 40 bytes= 2240 bytes bBlakley= 8 · 5 · 4 bytes + 40 bytes = 160 bytes

7.5 Discussion

Table 7.1: The storage requirements in bytes b of the proposed (t, n)-threshold verification scheme for the additional configura- tions. The values for the naive approach are also given for reference. H is the desired strength of the authentication scheme. n and t are the portfolio parameters.

H n t bnaive bBlakley bShamir

39,42 9 6 3360 364 200 52,56 12 8 19800 712 248 65,70 15 10 120120 1390 536 78,84 18 12 742560 2200 632 91,98 21 14 4651200 3568 728 105,12 24 16 29418840 5416 824

Analogously to the PIN-level, at the password-level the variant based on Blakley secret sharing is the most efficient option at the password-level.

Beyond password-level security

Table 7.1 shows the storage requirements of the six additional configurations based on the settings outlined in section 7.4.4. From the data it becomes apparent that the more authorised subsets there exist for one password, the more storage is required by both, the naive approach and the (t, n)-threshold verification variants. However, due to the different growths of the required storage in both approaches (polynomial vs. factorial) the difference between the naive approach and the (t, n)-threshold verification variants steadily increases. The (t, n)-threshold verification variants are substantially more efficient in terms of storage than the naive approach for large numbers of authorised subsets. However, the differences between the two variants become also more pronounced. While for the PIN-level and password-level the variant based on Blakley secret sharing is the more efficient choice, this reverses for larger configurations (i.e. larger values of n, t, and p).

7.5 Discussion

This section discusses the (t, n)-threshold verification scheme presented in this chapter along the results of the security and efficiency evaluation as well as the limitations of the two evaluations. Thereafter, it highlights possible next steps for the continuation of this work.

7.5.1 Results

This chapter introduces the (t, n)-threshold verification scheme, a novel verification scheme to facilitate secure and efficient verification in portfolio authentication schemes. Two (t, n)-threshold verification variants are proposed. The first variant is based on Blakley secret sharing and therefore uses hyperplane geometry to derive a shared secret from all authorised subsets of password elements. The second variant is based on Shamir secret sharing and therefore uses Lagrange interpolation to derive a shared secret. The storage efficiency of both variants was evaluated against a naive approach and their security properties discussed.

In terms of storage efficiency, the comparison revealed that both of the proposed (t, n)-threshold verification variants require substantially less storage space for the verification information than the naive approach. The required storage of the (t, n)-threshold verification scheme grows only polynomially, while the storage

7 The (t,n)-threshold Verification Scheme for Portfolio Authentication

of the naive approach grows factorially in the length of the password and the size of the authorised subsets. The efficiency in terms of storage space can be regarded as the most important trait of the (t, n)-threshold verification scheme. The storage requirement of the (t, n)-threshold verification scheme is four times (variant 2) to six times (variant 1) smaller in the PIN-level security setting and twelve times (variant 2) to fourteen times (variant 1) smaller in the password-level security setting than for the naive approach. The additional configurations let this difference become even more apparent: the longer the password is (assuming the same portfolio overhead), the larger the difference becomes.

Furthermore, differences between the two (t, n)-threshold verification variants became apparent. While the first variant (based on Blakley secret sharing) is more efficient for small n, t, and p, the second variant (based on Shamir secret sharing) is more efficient for larger configurations. This is due to the usage of block ciphers in the second variant. The cipher’s block size leads to storage inefficiencies in small configurations, since smaller amounts of data are then simply padded with zeros and take the same space as larger amounts. However, depending on the specific application scenario, it might also be possible to further increase the storage efficiency of the second variant by (a) decreasing the block size of the cipher, (b) using a simple counter instead of a random IV, or (c) using a secure stream cipher instead of the block cipher. Yet, a full investigation of such variants constitutes future work. Overall, the differences between the two variants show that it is of the essence to be aware of one’s exact requirements in terms of the parameters n, t, and p when deciding for one of the two variants in terms of efficiency.

It is also important to acknowledge that using portfolio authentication with either approach imposes a penalty to storage efficiency. The storage requirement of both (t, n)-threshold verification variants is much larger than in the non-portfolio scenario, where only one hash of 40 bytes would have to be stored for a traditional password in this comparison. Yet, this additional storage requirement is not unreasonable: assuming the password-level security and an organisation with 30.000 user accounts, traditional text passwords would require 1.2 megabytes of storage capacity (40 · 300000 = 102000000 bytes) and the use of (t, n)-threshold verification would require 4.8 megabytes of storage (160 · 300000= 408000000 bytes).

In terms of security, the properties regarding secure storage and the guessing resistance of the (t, n)-threshold verification variants were investigated. Regarding the secure storage of the authentication information it could be shown that the choice of a secure KDF allows secure storage for both (t, n)-threshold verification variants. Regarding the guessing resistance, the verification scheme can be adapted to the desired strength of the authentication scheme by choosing p large enough according to equation (7.5). However, it becomes apparent from equation (7.7) and equation (7.8) that balancing the storage requirements and the resistance to guessing attacks by carefully choosing the parameter p can be of the essence. For PIN-level or password-level secrets and in scenarios where storage efficiency is not of utmost importance, this is not critical. However, when longer secrets are stored and storage efficiency is of the essence, the advantage in terms of storage can decrease.

Additionally, the (t, n)-threshold verification variant based on Shamir secret sharing relies not only on an appropriate KDF, but also on a symmetric cipher, rendering implementations potentially more complex. Therefore, implementers should mind the different mathematical structures (hyperplane geometry versus Lagrange interpolation) underlying the two variants and base their decision of which variant to implement not only on efficiency considerations.

7.6 Conclusion

7.5.2 Limitations

While this chapter discusses the security properties of the (t, n)-threshold verification scheme, it is conceivable that detailed cryptanalyses using techniques such as lattice-based algorithms or a modelling using integer linear programming might potentially necessitate to re-evaluate the choice of the parameters n, t, and p for either of the two (t, n)-threshold verification variants. Thus, it might be a worthwhile direction of future work to apply such techniques.

With respect to the efficiency analysis, several configurations based on the usual portfolio overhead of o=3₂ were presented. Depending on the specific use case, evaluations including other portfolio overhead values and different sizes for the alphabet might be required for practitioners to get an overview of possible configurations more easily. Also, salt values longer than the 64 bits chosen from the recommendations in the literature might increase security, but also impact storage efficiency. The 64 bits represent the lower bound of the recommendations in the literature and this value was chosen, since it minimises the impact of the salt on the overall storage comparison.

7.5.3 Next Steps

From the work presented in this chapter, two lines of future work emerge:

• To illustrate the application of the (t, n)-threshold verification scheme to different authentication schemes, concrete use cases should be developed which can serve as blueprints for researchers and practitioners seeking to implement portfolio authentication schemes based on (t, n)-threshold verifica- tion.

• To strengthen the evaluation of the security properties, additional cryptanalyses using lattice-based algorithms or integer linear programming modelling should be conducted by experts in the respective fields.

To facilitate the usage of the (t, n)-threshold verification scheme in portfolio authentication schemes, the next chapter presents three use cases of the scheme’s application as blueprints for future implementations. The additional cryptanalyses are left explicitly as future work for experts in the respective fields.

7.6 Conclusion

This chapter introduced the (t, n)-threshold verification scheme. It serves as an important enabler for new and existing portfolio authentication schemes, offering secure and efficient password verification. The two (t, n)-threshold verification variants offer several points of differentiation.

The first variant is based on Blakley secret sharing and therefore uses as underlying mathematical structure hyperplane geometry. It seems to be the most efficient option for small n, t, and p. Also, it easily offers all optional operations. In terms of security it only relies on the security of the used KDF.

The second variant is based on Shamir secret sharing and therefore uses Lagrange interpolation as underlying mathematical construct. It seems to be the most efficient option for higher security configurations (i.e. beyond PIN-level security). Analogously to variant 1, it offers all optional operations. However, in terms of

7 The (t,n)-threshold Verification Scheme for Portfolio Authentication

security it not only relies on the security of the used KDF, but also on the security of the used symmetric block cipher.

8

Use Cases of the (t,n)-threshold Verification Scheme

As described in the previous chapter, the (t, n)-threshold verification scheme is an enabler of secure and efficient storage for a wide variety of authentication schemes. In this chapter three use cases of applying the (t, n)-threshold verification scheme are presented. Two of these use cases represent the original knowledge- based authentication application scenario: graphical recognition-based passwords (section 8.1) and partial passwords (section 8.2). In addition, the third use case will discuss the application of the (t, n)-threshold verification scheme in a different scenario: the ZeTA authentication scheme which is based on the human ability to connect semantically related concepts (section 8.3). In each use case the mappings of the elements in the respective authentication scheme onto the elements of the (t, n)-threshold verification scheme are described along the procedures necessary for enrolment as well as authentication and verification.

Last but not least, the use cases as well as further areas of application spanning different types of authen- tication schemes and enabling redundancy for authentication factors in case of loss, damage or theft are discussed (section 8.4). Section 8.5 concludes this chapter.

Contributions described in this chapter:

• Description of three use cases for the (t, n)-threshold verification scheme: graphical recognition- based passwords, partial passwords, and the ZeTA authentication scheme.

• Discussion of further areas of application beyond the three use cases described in detail.

Parts of the results described in this chapter have been published in:

• P. Mayer and M. Volkamer, “Secure and Efficient Key Derivation in Portfolio Authentication Schemes Using Blakley Secret Sharing”, Annual Computer Securit Applications Conference (ACSAC), 2015, pp. 431–440.

• P. Mayer and M. Volkamer, “Poster: Secure Storage of Masked Passwords”, European Symposium on Security and Privacy Posters (Euro S&P Posters), 2017

• A. Gutmann, K. Renaud, J. Maguire, P. Mayer, M. Volkamer, K. Matsuura, and J. Muller-Quade, “ZeTA-Zero-Trust Authentication: Relying on Innate Human Ability, Not Technology”, European Symposium on Security and Privacy (Euro S&P), 2016, pp. 357–371.

8 Use Cases of the (t,n)-threshold Verification Scheme