scieee AI-readable full text Open interactive document viewer

Shesmu DBDsys: a Solution for Safer Data Sharing in the Case of Directed Blood Donation

Roskó, Tibor

Abstract

Publicly shared numerous types of personal data further increase the possibilities for misuses, especially sensitive data, such as health or biometric data. Our focus is on the phenomenon when people publicly share their or others' personal data related to directed blood donation in order to find donors on the Internet without any protection, which can be the source of identity theft or fake fundraising crimes. To solve this problem and help people to protect their data in this relation, we designed and implemented a possible solution called Shesmu DBDsys, which applies AES-256-GCM encryption to protect and QR code to share data. Shesmu does not store any personal data and ensures that potential donors can only access personal information related to the recipient if they perform a successful donation. We also carried out experimental software analyses to validate the correctness of our implementation and to give proposals, such as the appropriate size of the QR code.

Full text

Shesmu DBDsys A Solution for Safer Data Sharing in the Case of Directed Blood Donation by Roskó, Tibor Faculty of Informatics of the University of Debrecen orcid.org/0000-0002-6521-9447 This work was published on November 18, 2023, under the doi number https://doi.org/10.5281/zenodo.10144520 and is licenced under the Creative Commons AttributionNonCommercial-NoDerivatives 4.0 International Licence (https://creativecommons.org/licenses/by-ncnd/4.0). Roskó, Tibor He is a self-employed Computer Science consultant, translator and researcher. His research is related to the Faculty of Informatics of the University of Debrecen. He focuses on the analysis of people's privacy awareness and password management, especially globally centralised user authentication solutions and online privacy. For more information, please visit www.rtibor.hu and the Zenodo repository. 2 Publicly shared numerous types of personal data further increase the possibilities for misuses, especially sensitive data, such as health or biometric data. Our focus is on the phenomenon when people publicly share their or others' personal data related to directed blood donation in order to find donors on the Internet without any protection, which can be the source of identity theft or fake fundraising crimes. To solve this problem and help people to protect their data in this relation, we designed and implemented a possible solution called Shesmu DBDsys, which applies AES-256-GCM encryption to protect and QR code to share data. Shesmu does not store any personal data and ensures that potential donors can only access personal information related to the recipient if they perform a successful donation. We also carried out experimental software analyses to validate the correctness of our implementation and to give proposals, such as the appropriate size of the QR code. Keywords: •directed blood donation •privacy protection •encrypted data in QR code •privacy awareness •cybercrimes related to data concerning health 3 1. Introduction "Donate blood and save lives!" is the slogan of almost all blood services. The role of blood donation is indisputable all over the world to be able to treat medical cases that cause blood loss, for example, surgeries, accidents or serious injuries. In this paper, our focus is on the Hungarian blood donation system, especially directed blood donation, where the donor (who gives blood) designates the recipient (who receives blood) of the donation [1]. When a patient with a rare blood type, such as B-, AB+ or ABneeds help, directed or organized blood donation could be the best – sometimes the only one – opportunity to collect enough blood for treatment. The process of blood donation is based on the AB0 and RhD blood systems, so the blood type can be one of the following: 0+, 0-, A+, A-, B+, B-, AB+ or AB-. In the case of blood donation, it is a very important property because the donor and the recipient have to have the same blood type, but naturally, there are some exceptions when different blood types can be used, such as 0blood can safely be donated to everyone or A+ to an AB+ recipient as well, but in other cases, different blood might cause complications. All compatible combinations are summarised in Table 1 [2]. 0+ 0A+ AB+ BAB+ AB0+ x x 0x A+ xxxx Ax x B+ x x x x Bx x AB+ xxxxxxxx ABx x x x Table 1: Compatible blood types (source: https://www.blood.co.uk/why-give-blood/blood-types) Decree 3/2005 (II. 10.) authorises the Hungarian National Blood Transfusion Service (Hungarian acronym: OVSZ) to coordinate the process, collect blood and manage personal data related to the donation [3]. In the case of directed donation, these personal data, apart from the donor's personal data, are the recipient's social security number (SSN), name, birth date, blood type and the city and name with the department of the health care institution treating the recipient. Section 14 (3) of Decree 3/2005 (II. 10.) allows the donor to designate a recipient who can get their blood by giving the previously listed recipient's data via a paper-based statement [3]. To do that, the donor needs to know the recipient's data. In most cases, recipients or their close relatives usually share the information required by the directed donation process on the Internet, such as Facebook or news sites. In some cases, these have been shared without the clear consent of the recipient. Nowadays, in the Coronavirus crisis the number of these shares is steadily increasing because the number of donors has significantly decreased, in other words, there are not enough blood products for all treatments. Although the number of directed donations was only about 20 000 out of the total 380 000 blood donations in 2019, publicly available personal data, especially data on health, which is one of the special categories of personal data stated in Article 9 of the General Data Protection Regulation (GDPR), can be the source of various crimes [4]. 4 The number of misused personal data was 1478 in 2019, and the number of misused social security numbers was 55 in 2017 based on the Hungarian police statistics (source: bsr.bm.hu). A typical crime is using real personal data for fake fundraising activities or in fake news portals to get clicks. Based on the ENISA Threat Landscape Report 2018, the overall trend of identity theft in 2018 increased, and it is safe to conclude that the increasing number of data breaches can be the reason for that [5]. We have investigated online sites and posts in Facebook groups to measure how a big problem that is, and we have found several posts (at least 77) containing various personal data, such as name, social security number, blood type, address, religion and birth data that have been available for at least one or two years, but some have been available for six years. Based on the paper [6], we can confirm that there are many data left behind, forgotten or ignored intentionally. Confidential personal data are just lying around somewhere until someone makes an effort and takes the time to search for them in the right place. Once found or retrieved from bad disposal methods, they can be used for illegal or unethical activities. To tackle the problem, we designed and implemented a possible solution for the recipients to safely share their data required by the directed donation online on the Internet as well as on paper. encryptionService and decryptionService are the bases that use the AES-256-GCM (Advanced Encryption Standard, Galois/Counter Mode) encryption algorithm to encrypt and decrypt the recipient's data and that generates a QR code for sharing the encrypted data set. It cooperates with the Amazon Web Services Key Management Service CloudHSM (AWS KMS; HSM: Hardware Security Module) service in order that the AES-256 key will be securely stored. We focused on making this solution to be as simple as possible to use and not to require a huge amount of resources to be integrated into the existing systems. And nor does our solution store any personal data. The current paper presents our results organised into five sections. The first is the Methodology introducing the method of data collection, the process of analysis, applied softwares and resource URLs. It is followed by the Reasons for the development, the Results introducing the design and development of Shesmu DBDsys components and the Validation presenting correctness information about the algorithms and parameters used. In the subsections of the Results, we give a detailed description of the encryptionService, decryptionService and the selection process of the encryption algorithm. Finally, the Conclusion reviews the key features of Shesmu DBDsys and introduces future development opportunities. 5 2. Methodology In previous observations, we found that people share their personal data required by directed blood donation on Facebook and various websites to get donors. Based on this experience, we have analysed two groups on Facebook to identify what types of information are included in these posts. The "Debrecenben hallottam" is a private group, which means that posts can only be seen by the members. It was founded in February 2014. On 23rd December 2020, it had 102825 members. In this group, we could find 25 posts related to directed blood donation using "véradás" keyword in the search. The "VÉRPLAZMA DONOROK MINDENHONNAN" is the second group we investigated, which is a public group, so anyone can see the posts. It was founded in October 2017. On 23rd December 2020, it had 3287 members. In this group, we could find 55 posts related to directed blood donation using "irányított" keyword in the search. For the analyses, records from the two groups have been merged and duplications have been eliminated. The result is 77 posts containing various personal information, such as name, mother's name, religion or social security number (SSN). Table 2 summarises the result, where "included" means the number of posts that the particular attribute is included in and the "percentage" is the percentage of its distribution for the specific attribute, while non-included indicates the number of posts that the specific attribute does not appear in. The data set is available in our Zenodo repository [7]. included non-included percentage of included name 77 0 100.00% birth_date 76 1 98.70% blood_group 70 7 90.90% ssn 75 2 97.40% treatement_place 69 8 89.60% birth_place 38 39 49.40% reason 31 46 40.30% exchange_blood_statement 22 55 28.60% photo 12 65 15.60% treatment_date 16 61 20.80% address 4 73 5.20% mothers_name 19 58 24.70% doctors 18 59 23.40% religion 1 76 1.30% occupation 2 75 2.60% id_document_number 1 76 1.30% identifier_number 1 76 1.30% dead_info 1 76 1.30% Table 2: Descriptive statistics of the data set of two Facebook groups in the case of directed blood donation 6 To design and develop an appropriate solution for recipients to safely share their personal data required by directed blood donation, we interviewed some specialists of the OVSZ to understand and analyse the process of directed blood donation. We found that an encryption solution can eliminate the vulnerabilities caused by publicly shared recipient's personal data. This assumption has already been confirmed in [8]: by encrypting the content of QR codes, the data can still be confidential, and this encryption can also protect against the decryption of information without knowing the encryption key. We analysed the recommendations of the National Institute of Standards and Technology (NIST) in the document [9] to find the appropriate encryption algorithm. AES-256-GCM was chosen since GCM mode provides both confidentiality and integrity for encrypted data, and it provides the additional feature of making decryption fail in case of a forging attack [8]. In our solution following the recommendations of the NIST Federal Information Processing Standards (FIPS) 140-2 document [10], we applied a HSM system to securely store AES keys. A detailed discussion is provided in Section 4.1. To validate our implementation, we carried out experimental software analyses to informally verify the correctness of openssl_encrypt and openssl_decrypt functions of PHP OpenSSL extension in the case of AES-256-GCM block cipher mode based on NIST Cryptographic Algorithm Validation Program (CAVP), and to determine the maximum number of characters from which we generate a QR code that can be processed by ordinary tools, such as an online QR code reader service or a mobile application. To carry out our experimental software analyses, we used the XAMPP v7.4.8 (PHP-7.4.8, OpenSSL 1.1.1) platform as a test environment to build up and run our scripts. A detailed discussion of these results is presented in Section 5; scripts and data sets are available in the Zenodo repository [11]. In the case of OpenSSL 1.1.1 PHP library, we implemented a validator script and selected the relevant test vectors from the NIST GCM test vectors package; the script source code and test vectors are available in the Zenodo repository [12]. In our analysis, we tested the openssl_encrypt and openssl_decrypt functions with zero and 408 bits plain text lengths – IV length 96 bits and TAG length 128 bits –, and could verify their correctness. We also tested the built-in failure of test vectors in the case of openssl_decrypt function and found that the function had correctly worked and resulted in failure on the specific inputs. On the other hand, to validate our implementation and determine maximum how many input characters can be used for the QR code to be readable, we made an automatic test with our script using the goQR.me API and manual scans using a smartphone with a 13MP camera and scanner applications, such as Kaspersky QR Scanner (v1.7.4.232) and Flado QR scanner (v1.1.0.8). Our automatic script generated random data and tested the creation and reading processes, and during this, it generated 400 pieces of QR code in PNG format and a log file with the following information. char_number qr_size round random_data_length encrypted_temp_length iv_length tag_length data_key_encrypted_length b64_encrypted_temp_length b64_iv_length b64_tag_length b64_data_key_encrypted_length b64_qr_value_length read_fail 7 Because Shesmu is an open-source project under version 3 of the GNU General Public License (GPLv3) licence, its source code is available on GitHub, some promo videos on YouTube and the related research data sets on Zenodo. Source code on GitHub https://github.com/srt2015/Shesmu_DBDsys YouTube videos encryptionService demo https://youtu.be/siew1M58aKI decryptionService demo https://youtu.be/q3D7CMa-Mjo data sets on Zenodo NIST CAVP analyses of PHP OpenSSL encrypt/decrypt functions [12] https://doi.org/10.5281/ZENODO.3978386 QR-code generation and scanning experimental analyses [11] https://doi.org/10.5281/ZENODO.3978427 Facebook group posts related to directed blood donation [7] https://doi.org/10.5281/ZENODO.4411040 NIST CAVP – National Institute of Standards and Technology Cryptographic Algorithm Validation Program https://csrc.nist.gov/Projects/cryptographic-algorithm-validation-program/cavp-testing-blockcipher-modes Facebook groups "Debrecenben hallottam" – (information sharing in Debrecen, Hungary) https://www.facebook.com/groups/279288692229091 "VÉRPLAZMA DONOROK MINDENHONNAN" – (blood plasma donors from everywhere) https://www.facebook.com/groups/707317849478617 privacy policy of goQR.me APIs https://goqr.me/de/rechtliches/datenschutz-api.html XAMPP v7.4.8 https://sourceforge.net/projects/xampp/files/XAMPP%20Windows/7.4.8/xampp-portablewindows-x64-7.4.8-0-VC15.zip/download Kaspersky QR Scanner (v1.7.4.232) https://play.google.com/store/apps/details?id=com.kaspersky.qrscanner Flado QR scanner (v1.1.0.8) https://play.google.com/store/apps/details?id=com.flado.qr_scanner 8 3. The detailed reason that motivated us to design Shesmu DBDsys As we previously introduced, nowadays, the online presence is steadily growing, more than sixty-seven per cent of the respondents daily use the Internet [13]. This tendency has become a source of many dangers, such as computer viruses, identity theft crimes or fake information. Publicly sharing several types of personal data, especially sensitive health or biometric information further increases the possibilities for misuse. In this section, we highlight why it is so important to deal with the phenomenon when people publicly share their or others' personal data related to directed blood donation. Which has become very common on Facebook and various news websites. In most cases, these are not their own data but belong to other recipients, such as family members, friends or strangers. We inspected 77 posts containing more additional information than the name, blood type, birth data and place of treatment that are really needed for the directed blood donation. The posts were publicly available for at least one or two years but the oldest one was available for six years. As can be seen in Table 2, several types of unnecessary attributes are present in the posts, while, information required by directed donation is not complete, because the information on the place of treatment is missing in 10.40 per cent of the cases and blood type is also missing in 9.10 per cent, the name is the only one, which is present in all cases. Another big problem is that the so-called four natural personal identifier attributes, such as name, mother's name, date and place of birth appear in 24.70 per cent. With the SSN, it can be an easy way for attackers to successfully perpetrate identity theft crimes, such as gathering more information about the victim using these attributes to act as an authority. For example, the attacker sends a specific spam email to the victim on behalf of a health insurance organization to gather more information, such as phone number, bank account or bank card information. In this coronavirus crisis, this is more severe because everyone prefers online administration. This worrying phenomenon was also highlighted in [6]. If many data are left behind, forgotten or ignored intentionally, once found or retrieved from bad disposal methods, they can be used for illegal or unethical activities. On the one hand, sharing personal data without the individual's clear consent does not comply with Article 6. 1/a of the GDPR, which requires previous consent to be given by the subject of data except when the processing of personal data is done by a natural person in the course of a purely personal or household activity [4]. On the other hand, it is extremely irresponsible, even if done with good intentions because criminals might misuse these data. For example, perpetrating identity theft or gathering more information using the posted attributes. Sharing others' personal data widely on the Internet cannot be in the course of a purely personal or household activity. Based on this, we might suppose that people do that because they do not have enough or deep knowledge of data protection regulations and about what crimes might be perpetrated with their publicly shared data. In our previous papers [14], [15], we demonstrate that people's privacy awareness is really low, and they do not tend to want to change it. Namely, only 25.75 per cent of them always or usually read privacy policies and terms, and a dominant part (48.31 per cent) are not interested in it. Besides that, people who are more educated and have broad and deep knowledge about possible thefts or privacy regulations tend to be more aware of their online behaviour, such as controlling the information they share online or reading policies and terms. 9 5. Validation The data set required by directed blood donation contains several attributes considered a special category of personal data by the GDPR, such as SSN, blood type, hospital, treatment or diagnosis [4]. Based on the NIST SP. 800-63, in the case of managing health information, it is recommended to consider the use of Authenticator Assurance Level 3 (NIST AAL3) to reduce the risk of data misuse or any type of cybercrimes. Shesmu, to comply with NIST AAL3 in the case of encryption, uses the services of FIPS 140-2 validated AWS KMS HSM [24]. In the case of privacy, we analysed the privacy policy of goQR.me APIs. We found that goQR.me, in the case of the create-qr-code service, does not save or archive the content of the generated QR code, and the generated graphic file is deleted from the cache within five minutes after delivery. In the case of the read-qr-code service, the graphic file sent to read is deleted immediately after the request has been processed and is not archived. The service server applies HTTPS in communication to protect transferred information. Finally, we will discuss our experimental software analyses to validate the QR code generation and read, and draw up proposals for settings of the generation. We expected that increasing the number of input characters requires a bigger QR code size, and we found that it can be true, particularly, in the case of printed QR scanning. Our script found that 200px size can be read by the goQR.me API until 700 input characters and over 700 characters, 300px can work properly but the smartphone-based scan is only stable with 400px or more. Paper [8] also confirmed that the rate of successful readings decreases when the data size increases. Results of QR code scanning with smartphone applications on both screen and paper are summarised in Table 3. QR code size (px) maximum input characters could be scanned 200x200 400 300x300 700 400x400 900 500x500 1000 Table 3: Results of QR code scanning with smartphone applications on both screen and paper These results suggest that it is recommended to consider the optimization of QR code size concerning the number of input characters, because, based on our example recipient's QR code generation, 400 input characters can be more than enough; and 200px is an easily usable size for general purposes. To save characters, we applied predefined scheme-based concatenation using hashtags as separators on the input data set. goQR.me service could generate QR codes from a maximum of 1900 input characters, which means the total number of characters is 2827 (close to the maximum of QR code capacity). Where the number of input characters only refers to the information we want to share, such as the recipient's attributes and the total number of characters refers to all the information stored in the QR code including such encryption attributes as TAG, IV or encrypted data key. 16 6. Conclusion In this paper, we introduced a solution called Shesmu DBDsys designed and developed to protect publicly shared personal data required by directed blood donation. One property of Shesmu is that it does not store any personal information to perform the data provision service. In the first design, we wanted to store the recipient's data required by directed blood donation with a validity time interval to ensure the erasure of unnecessary data, but we identified some resourceintensive implementation, such as authentication and authorisation of recipients and reaching information of recipients' treatment, especially the end date of the treatment. After discussing these problems with the OVSZ specialists, we found that building a database is unnecessary because giving directed blood to a recipient who is not under treatment does not cause problems or get lost as, after 14 days, the donated blood product will be used in a normal donation [1]. Knowing this fact, we implemented the introduced QR code-based service instead of building a database. Of which key is the application of AES-256-GCM encryption in cooperation with FIPS 140-2 validated AWS CloudHSM and KMS services. Another value or feature of Shesmu is that the donor will only know the recipient's personal data if they apply for directed blood donation and they can perform it, in other words, their blood is appropriate for the recipient. Alternatively, publicly sharing the recipient's personal data on the Internet or sharing data on demand in a closed Facebook group causes anyone can know the recipient's personal data. An additional proposal for the future to improve personal data protection might be that donors should not know, exactly read the recipient's SSN in the process, only the OVSZ system, which might perform data validation against the given SSN and the recipient's other data, such as name and birth date belong together. To perform this, the OVSZ system might use a web service of the National Health Insurance Fund of Hungary (Hungarian acronym: NEAK). Besides security, easy usability was also essential because if users find it uncomfortable or difficult to use, they will not use it. To avoid this situation, Shesmu has a simple online form for users to easily generate a QR code from the recipient's required personal data. The generated PNG image file can easily be downloaded and shared on the Internet or on paper after printing. In addition, we investigated the phenomenon when people publicly share their personal data on the Internet, especially on Facebook or news portals, primarily in the case of directed blood donation. The vulnerable issue that results highlight is not only limited to this topic but to other cases when people publicly share their personal data, for example, sharing images publicly of documents (e.g. ID card, driving licence or formal letter) on Facebook without covering sensitive information or posting photos about their certificates without covering personal data. 17 7. Acknowledgement We would like to thank them for their support: •Hungarian National Blood Transfusion Service for suggestions and comments •Hungarian National Police Headquarters for crime statistics •The Document Foundation for LibreOffice software •Corporation for Digital Scholarship for Zotero software •CERN, the European Organization for Nuclear Research for Zenodo site •Nyilas Istvánné (University of Debrecen) for grammar review EFOP-3.6.3-VEKOP-16-2017-00002 of the University of Debrecen partially supported this research. We wish to confirm that there are no known conflicts of interest associated with this publication, and there has been no significant financial support for this work that could have influenced its outcome. 18 8. References [1] K. Baróti-Tóth, Z. Csernus, I. Hoffer, B. Jenei, V. Szekeres, and K. Vörös, Transzfúziós Szabályzat. Országos Vérellátó Szolgálat, 2016. [2] L. Dean, Blood Groups and Red Cell Antigens [Internet]. Bethesda (MD): National Center for Biotechnology Information (US), 2005. [Online]. Available: https://www.ncbi.nlm.nih.gov/books/NBK2261/ [3] Decree 3/2005 (II. 10.). [Online]. Available: http://njt.hu/cgi_bin/njt_doc.cgi? docid=92691.363968 [4] Regulation (EU) No 2016/679 of The European Parliament and of The Council. 2016. [Online]. Available: https://eur-lex.europa.eu/legal-content/HU/TXT/ELI/?eliuri=eli:reg:2016:679:oj [5] “ENISA Threat Landscape Report 2018,” 2019. doi: https://doi.org/10.2824/622757. [6] S. B. Alkhadhr, M. A. Alkandari, and T. Song, “Cryptography and randomization to dispose of data and boost system security,” Cogent Eng., vol. 4, no. 1, p. 1300049, Jan. 2017, doi: 10.1080/23311916.2017.1300049. [7] T. Roskó, “Shesmu DBDsys: Facebook group posts related to directed blood donation,” Jan. 2021, doi: 10.5281/ZENODO.4411040. [8] R. Focardi, F. L. Luccio, and H. A. M. Wahsheh, “Usable security for QR code,” J. Inf. Secur. Appl., vol. 48, p. 102369, Oct. 2019, doi: 10.1016/j.jisa.2019.102369. [9] E. Barker, “Guideline for using cryptographic standards in the federal government: SP.800175B,” National Institute of Standards and Technology, Gaithersburg, MD, Mar. 2020. doi: 10.6028/NIST.SP.800-175Br1. [10] “Security requirements for cryptographic modules: FIPS 140-2,” National Institute of Standards and Technology, Gaithersburg, MD, May 2001. doi: 10.6028/NIST.FIPS.140-2. [11] T. Roskó, “Shesmu DBDsys: QR-code generation and scanning experimental analyses,” Zenodo Repos., Aug. 2020, doi: 10.5281/ZENODO.3978427. [12] T. Roskó, “Shesmu DBDsys: NIST CAVP analyses of PHP OpenSSL encrypt/decrypt functions,” Zenodo Repos., Aug. 2020, doi: 10.5281/ZENODO.3978386. [13] A. B. Jibril, M. A. Kwarteng, R. K. Botchway, J. Bode, and M. Chovancova, “The impact of online identity theft on customers’ willingness to engage in e-banking transaction in Ghana: A technology threat avoidance theory,” Cogent Bus. Manag., vol. 7, no. 1, p. 1832825, Jan. 2020, doi: 10.1080/23311975.2020.1832825. [14] T. Roskó and G. J. Szőllősi, “Behind passwords: An analysis of preliminary results in order to understand how users protect their privacy,” First Monday, Jul. 2021, doi: 10.5210/fm.v26i8.10616. [15] T. Roskó and G. J. Szőllősi, “An in-depth analysis of People’s online privacy awareness,” Nov. 2023, doi: 10.5281/ZENODO.10070172. [16] E. B. Kim, “Information Security Awareness Status of Business College: Undergraduate Students,” Inf. Secur. J. Glob. Perspect., vol. 22, no. 4, pp. 171–179, Jul. 2013, doi: 10.1080/19393555.2013.828803. [17] R. Fatima, A. Yasin, L. Liu, J. Wang, W. Afzal, and A. Yasin, “Sharing information online rationally: An observation of user privacy concerns and awareness using serious game,” J. Inf. Secur. Appl., vol. 48, p. 102351, Oct. 2019, doi: 10.1016/j.jisa.2019.06.007. [18] E. Barker, “Recommendation for key management (SP 800-57),” National Institute of Standards and Technology, Gaithersburg, MD, May 2020. doi: 10.6028/NIST.SP.800-57pt1r5. 19 [19] E. Barker and A. Roginsky, “Transitioning the use of cryptographic algorithms and key lengths: SP.800-131A,” National Institute of Standards and Technology, Gaithersburg, MD, Mar. 2019. doi: 10.6028/NIST.SP.800-131Ar2. [20] D. A. McGrew and J. Viega, “The Galois/Counter Mode of Operation (GCM),” May 2005. [Online]. Available: https://csrc.nist.rip/groups/ST/toolkit/BCM/documents/proposedmodes/ gcm/gcm-revised-spec.pdf [21] D. A. McGrew and J. Viega, “The Security and Performance of the Galois/Counter Mode of Operation (Full Version).” 2004. [Cryptology ePrint Archive, Report 2004/193]. Available: https://eprint.iacr.org/2004/193 [22] M. J. Dworkin, “Recommendation for block cipher modes of operation: SP.800-38D,” National Institute of Standards and Technology, Gaithersburg, MD, 2007. doi: 10.6028/NIST.SP.800-38d. [23] “Protecting data with envelope encryption,” IBM Cloud Docs. [Online]. Available: https://cloud.ibm.com/docs/key-protect?topic=key-protect-envelope-encryption [24] P. A. Grassi, M. E. Garcia, and J. L. Fenton, “NIST Special Publication 800-63-3 Digital Identity Guidelines,” National Institute of Standards and Technology, Gaithersburg, MD, Jun. 2017. doi: 10.6028/NIST.SP.800-63-3. 20