AU2022283634A1 - System and method for exchange of data and/or secret keys - Google Patents

System and method for exchange of data and/or secret keys Download PDF

Info

Publication number
AU2022283634A1
AU2022283634A1 AU2022283634A AU2022283634A AU2022283634A1 AU 2022283634 A1 AU2022283634 A1 AU 2022283634A1 AU 2022283634 A AU2022283634 A AU 2022283634A AU 2022283634 A AU2022283634 A AU 2022283634A AU 2022283634 A1 AU2022283634 A1 AU 2022283634A1
Authority
AU
Australia
Prior art keywords
request
server
key
aead
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
AU2022283634A
Inventor
Baixin LIU
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AU2022900535A external-priority patent/AU2022900535A0/en
Application filed by Individual filed Critical Individual
Publication of AU2022283634A1 publication Critical patent/AU2022283634A1/en
Abandoned legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0478—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload applying multiple layers of encryption, e.g. nested tunnels or encrypting the content with a first key and then with at least a second key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1483—Countermeasures against malicious traffic service impersonation, e.g. phishing, pharming or web spoofing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12—Details relating to cryptographic hardware or logic circuitry
    • H04L2209/125—Parallelization or pipelining, e.g. for accelerating processing of cryptographic operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication

Abstract

There is provided a computer-implemented method for a client computer to securely exchange data with a server computer. The method may comprise: initiating a request of multiple encryption to the server computer, receiving a response to the request from the server computer if a second request identifier in the response matches a first request identifier in the request, retrieving each server key identifier for the server AEAD pipeline from the response metadata to obtain each server secret key for the server AEAD pipeline, identifying each encryption construction of the server AEAD pipeline corresponding to each server key identifier, if the response ciphertext and the response metadata is authenticated with the response authentication information based on the server AEAD construction of the server AEAD pipeline and the server secret key for the server AEAD construction of the server AEAD pipeline, decrypting the response ciphertext with the server AEAD pipeline to obtain the response payload. 2/14 API Server Queue handler lieployments and Secrets Runtime: Encrypted data Secrets encryption key Shared secret at rest 191 Private key 192 Client certificate 194 Regulator FO MR system in data centre 120 internet Firewall Work Station Registration Reverse Proxy Secrets encryptionteey System Server with 197 195 Mutual authentication API credentials Shared secret Compliance Private CA key Work System 194 Station 196 198 Regulator office 190 FIG 1 B FORMVR remote deployment and on-premise connector with mutual authentication

Description

2/14
API Server Queue handler lieployments and Secrets Runtime: Encrypted data Secrets encryption key Shared secret at rest 191 Private key 192 Client certificate
Regulator FO MR system in data centre 120
internet
194
Firewall
Work Station Registration Reverse Proxy Secrets encryptionteey System Server with 197 195 Mutual authentication
API credentials Shared secret Compliance Private CA key Work System 194 Station 196 198
Regulator office 190
FIG 1 B FORMVR remote deployment and on-premise connector with mutual authentication
SYSTEM AND METHOD FOR EXCHANGE OF DATA AND/OR SECRET KEYS
Field of the Invention
[0001] The present disclosure generally relates to cyber security of computer networks, and particularly, to a computer implemented method and system for exchange of data and/or secret keys between a client computer and a server computer.
Cross-reference
[0002] The present application claims priority from the Australian provisional patent application No. 2022901865, filed on 1 July 2022 by Baixin Liu, the Australian provisional patent application No. 2022900535, filed on 4 March 2022 by Baixin Liu, the contents of which are incorporated herein by reference in its entirety. The content of the Australian provisional patent application No. 2021903661, filed on 15 November 2021 by Baixin Liu, is also incorporated herein by reference in its entirety.
Background Art
[0003] Any discussion of the background art throughout the present disclosure should in no way be considered as an admission that such background art is prior art, nor that such background art is widely known or forms part of the common general knowledge in the field in Australia or any other country.
[0004] Transport Layer Security (TLS) is a protocol securing communications over the internet. It is a building block of other protocols such as Hypertext Transfer Protocol Secure (HTTPS, or HTTP over TLS), which uses TLS to encrypt communications. In a typical client-server communication using a TLS protocol, a server proves its identify with an X.509 server certificate signed by a trusted third-party Certificate Authority (CA). Computer systems may store the certificates of trusted CAs, and trust a server if it can provide a valid server certificate matching the hostname. In a Mutual TLS (mTLS) authentication process, the server presents a server certificate, and requires an X.509 certificate from a client before creating a secure connection. For many applications accessing a remote server owned by another party using the HTTPS protocol, a valid server certificate is the only factor to authenticate a server. While this trust model helps the interoperability of computer systems among individuals and decentralised organisations, attackers may abuse the chain of trust to impersonate servers, pass authentication, and exploit victim client computers by having certificates automatically issued after hijacking the internet traffic, for example through Border Gateway Protocol (BGP) Hijacking or Global Domain Name Server (DNS) Hijacking.
[0005] BGP Hijacking is hijacking internet traffic by publishing fake routing of Internet Protocol (IP) addresses. The internet consists of multiple big networks (Autonomous Systems, or AS) owned by internet service providers, governments, or large corporations. Each AS is assigned an Autonomous System Number (ASN). It is estimated that there are over 100,000 ASNs allocated in the world as of March 2021. BGP is one of the protocols for computer networks to find its way to the destination by IP address. Under normal circumstances each AS announces the BGP routing of IP addresses assigned to and managed by the AS. However, this is not always the case, as bad actors on the internet may announce BGP routing for IP addresses that they do not own. Some unsuspecting Autonomous Systems accept the routing information without validating ownership. The fake routing of IP addresses may trick client computers and other servers connecting from vulnerable networks to send data and credentials to a fake server. It happens at the network level and is relatively easy to manipulate remotely by hostile nation states or crime rings when they control or own one or more Autonomous Systems themselves.
[0006] Global DNS Hijacking refers to the unauthorised changes of domain name records to redirect traffic to fake servers. Computers communicate with each other using IP addresses. A Domain Name System translates human friendly domain names into IP addresses that computers can understand. Global DNS Hijacking could be done by guessing the password to a victim's account with the domain name registrar or DNS hosting account, tampering with authoritative DNS servers, compromising business email account, phishing, social engineering, or BGP Hijacking. During BGP Hijacking, the attacker may also set up a fake DNS server, tamper with DNS records for further exploitations.
[0007] Once an attacker has control over DNS records or the routing of target IP addresses, the attacker can request server certificates to be issued by a well trusted Certificate Authority (e.g. Let's Encrypt) using automated processes. Client computers cannot tell the difference and will negotiate a secret key with the fake server. Any data sent is automatically decrypted by the fake server who also has the negotiated secret key. The attacker can respond with malicious contents, or steal confidential data and authentication credentials for further exploitations.
[0008] Server impersonation authenticated with a valid certificate is more dangerous as client computers would have refused to connect otherwise. It may cause financial losses to some decentralised organisations, for example Virtual Asset Service Providers (VASPs). Some VASPs provide user-friendly strings to customers instead of digital wallet addresses which are random strings difficult to remember. When an originator of one VASP (Sending VASP) sends cryptocurrency to a recipient of another VASP (Receiving VASP), the Sending VASP needs to query the server of the Receiving VASP to get the wallet address. When an attacker impersonates the server of the Receiving VASP, the attacker may respond with wallet addresses under the attacker's control and steal a significant amount of cryptocurrency coins.
[0009] In some cases, server impersonation may have even more severe consequences to the general public or decentralised organisations such as regulators of different jurisdictions under Mutual Recognition Agreements (MRAs). An overview of MRAs is given below to explain the complexity and cyber security vulnerabilities of interconnected disparate systems owned by decentralised organisations in different jurisdictions.
[0010] Regulating activities with different local requirements creates barriers to the movement of people, causes regional skill shortages and negatively impacts economy. To encourage the mobility of workers in regulated occupations, governments enter into MRAs and recognise registration granted by other jurisdictions.
[0011] There are hundreds of MRAs in the world. Some MRAs have existed among federated states for decades. For example, under the Australian mutual recognition arrangements introduced in 1993, workers of certain occupations are entitled to be registered in a second state or territory on the basis of their existing registration without further assessment of their qualifications, skills, experience or character. Some MRAs are among countries. For example, Australian and New Zealand recognise occupational licenses under Trans-Tasman Mutual Recognition Arrangement (TTMRA). The members of the European Union have arrangements in place similar to the MRA in Australia.
[0012] The mobility of registered workers has significant economic values and addresses skill shortages in some areas. It is estimated by removing host jurisdiction license fees and allowing automatic recognition in Australia alone, the increased mobility of licensed workers will lead to an additional $2.4 billion AUD in economic activity over ten years as a result of savings to people and businesses, productivity improvements and extra surge capacity in response to natural disasters. The overall economic values of licensed workers' mobility are believed to be much higher. Thus, the efficiency and effectiveness of implementing mutual recognition schemes are useful and valuable to improve labour mobility and economic growth. The ease of use, automation and improvement of MRA efficiency are highly desirable among regulators and stakeholders.
[0013] Traditionally registered workers submit paperwork to regulatory authorities in the host jurisdiction to apply for registration under an MRA. The host jurisdiction verifies the registration with the workers' home jurisdiction manually by mail, fax or email. These manual processes take weeks or even months, impose unnecessary costs and delays, impede individuals and businesses operating across borders, and inhibit rapid responses to natural disasters and crises.
[0014] Australian Government Productivity Commission reviewed the coverage, efficiency and effectiveness of the MRA and TTMRA, and published a research report in year 2003, 2009 and 2015 respectively. In the 2015 report, the Commission found there would be cost savings from automating the manual MRA processes, and recommended governments expand the use of Automatic Mutual Recognition (AMR) to facilitate greater cross-border service provision and improve the efficiency of MRA for individuals and businesses. Some states in the eastern coast (Queensland, New South Wales, Victoria) had adopted AMR of selected occupations years before the Commission's review which started in year 2014.
[0015] In December 2020, all jurisdictions in Australia (except the Australian Capital Territory) signed an intergovernmental agreement on AMR which outlines, among other matters, jurisdictions' commitment to support the implementation of AMR including investment in information systems, and to facilitate collection and sharing of core information between jurisdictions.
[0016] AMR came into effect on 1 July 2021 in Australia. The AMR scheme removes the need for people to apply and pay for an additional registration or licence when working in another state or territory, saving them time and money. Registered workers need to notify the local registration authorities in the host jurisdiction if required. Regulators in some jurisdictions will potentially process more AMR notification paperwork without receiving application/license fees they used to charge. This change affects their revenue and budget. The likely increased uptake of AMR means regulators in home jurisdictions will have to manually process more requests for registration validation from counterparts in host jurisdictions. There will be more work to be done for the same or less money. Automated information sharing has become a necessity.
[0017] In October 2021, the Australian government announced a total budget of $6.5 million AUD as grants for small to medium enterprises to research and develop innovative solutions to improve information sharing between regulators and to improve the uptake of AMR. The information from the Australian government indicated that regulators had tried different sharing solutions available in the market with no satisfaction. The regulators were looking for an automated, fit-for-purpose information sharing solution to spend less time processing paperwork and focus more on monitoring and enforcing compliance.
[0018] Regulators represent authorities in a society and play a vital role in protecting the public's safety and wellbeing. Regulators may have legislated investigation, compliance and law enforcement responsibilities. Information compiled by regulators is often sensitive in nature, complex, and may contain personal, health and law enforcement activity information. Some information may even be classified. The information needs to be kept strictly confidential to protect privacy, law enforcement proceedings, the right of a person to a fair trial, and community safety practices. Failure in confidentiality and integrity of such information mayjeopardise public safety, the safety of officers, registered workers, whistle-blowers and their family members. Unauthorised access to or release of a regulator's confidential information may constitute a criminal offence. The use of personal information is also governed by applicable local privacy laws.
[0019] For security reasons, regulators' registration/compliance systems are typically isolated from the internet. Regulators across jurisdictions are of different sizes and various maturity levels in cyber security management. They have different budgets and disparate information systems, including systems hosted by a supplier, custom built digital solutions, legacy systems, and systems based on paper and faxes. Each regulator is responsible for its own cyber security system.
[0020] Each jurisdiction requires the ownership of data and control over hosting providers and data centres to avoid loss of data or loss of access due to law enforcement activities by another jurisdiction. This means a solution should be available as a product for each regulator to deploy on premise, or in a data centre of a regulator's choice. A centralised solution or Software as a Service (SAAS) model is unlikely to satisfy the data governance requirements of all jurisdictions under an MRA. To exchange data, the regulators' systems have to be exposed to the internet, and to the risks inherent on the internet. Border Gateway Protocol (BGP) Hijacking and Global Domain Name Server (DNS) Hijacking are two of such risks.
[0021] In some cases, it takes just a few seconds for DNS records to take effect and propagate to other DNS servers. A cyber attacker may alter DNS records to request a SSL/TLS certificate from a well trusted Certificate Authority (CA), and stealthily steal API secrets, authentication cookies and confidential data from unsuspecting client computers within minutes or less. After the hijacking, the attacker can then use the stolen credentials to tamper with data in one regulator's system, which is propagated to other regulators through mutual recognition, then subsequently pollute the entire network of regulators. In a more sophisticated case, the attacker may set up the fake server as a reverse proxy to the real server, become a man-in-the-middle, and intercept confidential information on the fake server. This may take much longer to detect as the system will work as expected otherwise. If a client certificate is found in a compromised email account, the fake reverse proxy may even work against servers protected by mutual authentication.
[0022] For interoperability, it is a common industry practice to authenticate API requests with API keys/secrets over HTTPS connection using the latest TLS 1.2 or 1.3 protocols. Some systems may provide Client Certificate Authentication (CCA, also known as mutual authentication, or mutual transport layer security, mTLS) as an extra security measure. Some systems monitor changes in DNS records or digital assets and send alerts to person in charge. These measures alone or combined are not adequate to mitigate the increased risks.
[0023] HTTPS protocol uses public-key cryptography (asymmetric cryptography) for a web server and client computers to negotiate a shared secret for subsequent encrypted communication. A client computer relies on the digital signature of a Certificate Authority to verify the authenticity of a server's public key, which changes from time to time due to key rotation and certificate renewal. In some cases it is not feasible to preload a web server's certificate on client computers. A client computer assumes the public key received from a web server is authentic if the public key is included in a valid certificate signed by a CA. Encryption using a dynamically negotiated key is broken if this assumption is not true during internet hijacking.
[0024] While CCA protects web services against stolen credentials by denying access if a valid client certificate is absent, CCA does not solve all the problems. CCA is not always supported by disparate systems. It is not always feasible to securely distribute client certificates and keys to individuals accessing the system remotely, for example the registered workers. Most importantly, CCA does not prevent web clients from sending confidential data and credentials to a fake server, which the fake server decrypts automatically. In some cases, the loss of confidential information may endanger the lives of the officers or the registered workers. A better, bulletproof solution is needed to always protect data confidentiality and integrity under all circumstances.
[0025] Bulletproof cyber security is the prerequisite of automation across regulators. Due to the authoritative and confidential nature, some regulators' systems are likely to become frequent targets of crime rings and hostile nation states. A network of mutually recognised systems is more lucrative to criminals. Once independent systems are connected to allow access to each other, the weakness of one system becomes the weakness of all connected systems. Cyber criminals may exploit a weakness in one system and subsequently trespass throughout the connected network. In case of system breaches, a regulator might be held responsible and answer to the public for errors or vulnerabilities of someone else. Thus, an automated information sharing solution should mitigate the increased and inherent cyber security risks of digitisation and exposure to the internet. Due to the unique decentralised nature of MRAs and AMR where each jurisdiction makes decisions independently, the solution needs to take into account the cyber security issues for all regulators, including the regulator with the least resources, smallest budget and lowest maturity level in cyber security management.
[0026] For security reasons, regulators' registration/compliance systems are typically located on premises and protected by intrusion-detection, antivirus software, firewall and physical isolation from the internet. Automated information sharing between regulators across jurisdictions inevitably connects and partially exposes regulators' systems to the internet, and consequently to cyber-attacks.
[0027] In order to match and exchange information between remote disparate systems, each regulator usually deploys an adaptor system and maps data to a consistent format agreed upon for sharing. As the regulators under an MRA belong to different jurisdictions, each regulator makes their own decision whether to buy or build an adaptor system, and where to deploy the system to meet local data governance and cyber security requirements.
[0028] While it is possible to push data to an adaptor system or to pull data into the adaptor system, the push approach will probably be selected more often than the pull option. The traditional wisdom of risk management is to define an internet exposure zone (danger zone), to make the minimum amount of data available for sharing, and to contain the cyber security risks. Some regulators may deploy the adaptor system outside the on premise firewall, or take advantage of a cloud solution to keep the firewall intact. Selected data is pushed from registration/compliance systems behind the firewall to the adaptor system, and exchanged with other regulators through API. This is especially the case when there are web hooks or data migration tools easily available to read data from existing systems locally and push data to the adaptor system. The decision makers of some regulators may prefer, or even insist, to push limited data to an adaptor system, and keep their existing systems and firewall intact. Pushing limited data from behind a firewall gives the perception that exposure risks are strictly under control and thus safer. A proposed push solution is similar to the traditional practices of sending out limited information by email, and it is unlikely that decision makers will reject this proposed solution. On the other hand, tearing a hole in the firewall and allowing access to mission critical confidential systems from outside sounds even riskier and may make the existing systems vulnerable. The decision makers of some regulators may strongly object to this approach, especially when there are other critical systems behind the firewall, and there are concerns of privilege escalation in an incident of system breach by exploiting critical and undisclosed vulnerabilities.
[0029] Legacy systems' lack of support to security protocols may also contribute to the popularity of the push approach. Transport Layer Security Protocol (TLS) version 1.2 published in 2008 and version 1.3 published in 2018 are the current protocols to establish secure connection over the internet. TLS version 1.0 published in 1999 and version 1.1 published in 2006 were deprecated by Internet Engineering Task Force (IETF) RFC 8996 in 2020. Legacy systems built before 2008 without support of TLS 1.2 are considered not secure for direct access over the internet. Pushing data to an adaptor system sounds like a more secure option, as long as the client and the adaptor system support TLS 1.2 or above.
[0030] In a typical procurement process, a regulator defines functional and technical requirements approved by a decision maker, then looks for solutions from approved suppliers and contractors, or builds the solution internally. When a built or bought solution passes internal audits and penetration tests, the solution would readily get approval from the decision maker who approved the requirements in the first place.
[0031] Regulators have various cyber security maturity levels and implement their adaptor systems independently following their standard development and procurement procedures. As a result of traditional wisdom and risk-aversion behaviours, one or more regulators will probably push data to the adaptor systems using available protocols and give API access to other regulators. By doing so, these regulators may unknowingly jeopardise confidentiality and integrity of data on the entire network.
[0032] When two previously bulletproof but isolated information systems are connected and accessed over the internet, the risk profiles have changed. Neither system will be bulletproof any longer, even using HTTPS protocol and mutual authentication with cryptographically strong algorithms that many people believe to be secure, until measures are taken to mitigate the increased and inherent cyber security risks as described in the present invention.
[0033] When regulators push data to adaptor systems, for interoperability, most likely these systems follow industry common practices and accept data in plaintext received over a TLS-encrypted connection after validating API key/secrets. Confidential data and API credentials could be sent to a fake server inevitably, which automatically decrypts data with the key it has exchanged with a victim client computer and respond with malicious messages. As a result, data confidentiality and integrity of the systems may be compromised.
[0034] Despite the fact that the regulators under MRAs/AMR have access to experienced software developers, cyber security experts, researchers, resources, budgets and years of time before the planned reforms and necessary automation, presently the Australian government is still offering millions of dollars as research and innovation grants for suitable solutions. Therefore, there is a need for an improved method or system to at least alleviate one or more of the above problems.
Summary of the Invention
[0035] There is provided a computer-implemented method for a client computer to securely exchange data with a server computer. The method may comprise:
storing a client AEAD pipeline comprising a symmetric encryption construction required by the server computer, a symmetric encryption construction required by the client computer, the client AEAD pipeline ending with a client authenticated encryption with associated data (AEAD) construction; storing a client secret key associated with each encryption construction of the client AEAD pipeline and identified by a client key identifier, each client secret key for the client AEAD pipeline being securely shared between the server computer and the client computer; initiating a request of multiple encryption to the server computer, the request comprising: a first request identifier identifying the request, request ciphertext representing request payload, the request ciphertext being generated based on the client AEAD pipeline, request metadata associated with the request payload and including each client key identifier for the client AEAD pipeline, and request authentication information authenticating the request ciphertext and the request metadata, the request authentication information being generated with the client secret key for the client AEAD encryption construction of the client AEAD pipeline, the request being encrypted with a Transport Layer Security (TLS) protocol; receiving a response to the request of multiple encryption from the server computer, the response being encrypted with the TLS protocol; decrypting the response with the TLS protocol to obtain response ciphertext representing response payload, response metadata associated with the response payload and comprising a second request identifier and each server key identifier for a server AEAD pipeline, each server key identifier identifying each server secret key for a server AEAD pipeline, the server AEAD pipeline including the symmetric encryption construction required by the server computer, the symmetric encryption construction required by the client computer, ending with a server AEAD construction, and response authentication information; extracting the second request identifier from the response metadata; comparing the second request identifier with the first request identifier; if the second request identifier matches the first request identifier, retrieving each server key identifier for the server AEAD pipeline from the response metadata to obtain each server secret key for the server AEAD pipeline, identifying each encryption construction of the server AEAD pipeline corresponding to each server key identifier, if the response ciphertext and the response metadata is authenticated with the response authentication information based on the server AEAD construction of the server AEAD pipeline and the server secret key for the server AEAD construction of the server AEAD pipeline, decrypting the response ciphertext with the server AEAD pipeline to obtain the response payload.
[0036] There is provided a computer-implemented method for a server computer to securely exchange data with a client computer. The method may comprise:
storing a server AEAD pipeline comprising a symmetric encryption construction required by the server computer, a symmetric encryption construction required by the client computer, the server AEAD pipeline ending with a server authenticated encryption with associated data (AEAD) construction;
storing a server secret key associated with each encryption construction of the server AEAD pipeline and identified by a server key identifier, each server secret key being securely shared between the server computer and the client computer;
receiving a request of multiple encryption from the client computer encrypted with a Transport Layer Security (TLS) protocol;
decrypting the request with the TLS protocol to obtain a request identifier, request ciphertext representing request payload, request metadata associated with the request payload, and request authentication information authenticating the request ciphertext and the request metadata, the request metadata comprising each client key identifier for a client AEAD pipeline;
retrieving each client secret key with each client key identifier; identifying each encryption construction of the client AEAD pipeline; if the request ciphertext and the request metadata is authenticated with the request authentication information, decrypting the request ciphertext with the client AEAD pipeline to obtain the request payload; and replying to the client computer with a response comprising response ciphertext representing response payload, response metadata associated with the response payload, the response metadata comprising the request identifier and each server key identifier for the server AEAD pipeline, and response authentication information authenticating the response ciphertext and the response metadata, the response ciphertext being a result of encrypting the response payload with the sever AEAD pipeline, the response being encrypted with the TLS protocol.
[0037] There is provided a computer-implemented method for a client computer to securely share secret keys with a server computer. The method may comprise:
storing an AEAD pipeline comprising a symmetric encryption construction required by the server computer, a symmetric encryption construction required by the client computer, the AEAD pipeline ending with a client AEAD construction;
storing a Network Secret Salt Key securely shared between the client computer and the server computer;
storing a hashing algorithm for both the client computer and the server computer;
storing a collection of key encapsulation mechanisms (KEM), the KEM collection comprising a client KEM required by the client computer, and a server KEM required by the server computer;
for each encryption construction of the AEAD pipeline, generating a pair of client private and public keys with each KEM in the collection of KEMs;
deriving an indexed secret key using a key derivation function (KDF) and the hashing algorithm for each encryption construction of the AEAD pipeline, parameters of the KDF including the Network Secret Salt Key as input key material, and a string comprising an exchange time and a sequence number indicating a symmetric encryption construction in the AEAD pipeline; encrypting request payload with each indexed secret key for the AEAD pipeline to obtain request ciphertext, the request payload comprising each client public key for the collection of KEMs; generating request authentication information authenticating the request ciphertext based on the AEAD encryption construction of the AEAD pipeline; initiating a request to the server computer, the request comprising a first request identifier, the request ciphertext representing the request payload, and the request authentication information, the request being encrypted with a TLS protocol; receiving a response from the server computer; decrypting the response with the TLS protocol to obtain response ciphertext representing response payload, response metadata comprising a second request identifier, and response authentication information authenticating the response ciphertext and the response metadata; comparing the first request identifier with the second request identifier; if the second request identifier matches the first request identifier, and the response ciphertext and the response metadata is authenticated with the response authentication information based on the indexed secret key for the AEAD construction of the AEAD pipeline, decrypting the response ciphertext with each indexed secret key for the AEAD pipeline to obtain the response payload; parsing the response payload to obtain a collection of server public keys; deriving input key material of the KDF from the collection of server public keys and each client private key; and deriving a shared secret key for each encryption construction in the AEAD pipeline using the KDF and the hashing algorithm with the Network Secret Salt Key as salt of the KDF.
[0038] There is provided a computer-implemented method for a server computer to securely share secret keys with a client computer. The method may comprise:
storing an AEAD pipeline comprising a symmetric encryption construction required by the server computer, a symmetric encryption construction required by the client computer, the AEAD pipeline ending with a client authenticated encryption with associated data (AEAD) construction; storing a Network Secret Salt Key securely shared between the client computer and the server computer; storing a hashing algorithm for both the client computer and the server computer; storing a collection of key encapsulation mechanisms (KEM), the KEM collection comprising a client KEM required by the client computer, and a server KEM required by the server computer; receiving a request from the client computer, the request being encrypted with a TLS protocol; decrypting the request with the TLS protocol to obtain request identifier, request ciphertext representing request payload, and request authentication information authenticating the request ciphertext; identifying each encryption construction in the AEAD pipeline; deriving an indexed secret key using a key derivation function (KDF) and the hashing algorithm for each encryption construction in the AEAD pipeline, parameters of the KDF including the Network Secret Salt Key as input key material of the KDF, and a string comprising an exchange time and a sequence number indicating the encryption construction in the AEAD pipeline; if the request ciphertext is authenticated with the request authentication information, decrypting the request ciphertext to obtain the request payload with the AEAD pipeline using each indexed secret key; parsing the request payload to obtain a collection of client public keys; for each encryption construction in the AEAD pipeline, generating a pair of server private and public keys with each KEM in the KEM collection; deriving input key material of the KDF from the collection of server private keys and each client public key; deriving a shared secret key for each encryption construction in the AEAD pipeline using the KDF and the hashing algorithm with the Network Secret Salt Key as salt of the KDF; constructing response metadata comprising the request identifier; encrypting response payload to obtain response ciphertext with the AEAD pipeline using each indexed secret key, the response payload comprising each server public key generated with the KEM collection; generating response authentication information authenticating the response ciphertext and the response metadata; and responding to the client computer with a response comprising the response ciphertext, the response metadata, and the response authentication information, the response being encrypted with a TLS protocol.
[0039] According to one aspect of the present invention, methods are provided for encrypting and decrypting data in cascades with a pipeline of one or more symmetric encryption constructions. For example, in some embodiments, a pipeline may comprise a symmetric encryption construction required by a client computer and a symmetric encryption construction required by a server computer, and always ends with an authenticated encryption with associated data (AEAD) construction. The AEAD construction uses a key size of at least 256 bits, a nonce size of at least 96 bits, and a tag size of at least 128 bits. The AEAD construction may use a stream cipher such as ChaCha20, or a block cipher such as AES with hardware acceleration. Each symmetric encryption construction uses a unique key and a unique nonce for encryption and decryption operations. Each operation cascades the output to the next operation in the pipeline. The decryption operations are performed in the reverse order of the symmetric encryption constructions in the pipeline.
[0040] According to another aspect, methods are provided for identifying secret keys and symmetric encryption constructions of a selected AEAD pipeline. For example, in some embodiments, both a client computer and a server computer may store secret keys with metadata including a unique key identifier and at most one associated symmetric encryption construction. Unique key identifiers may be sent in a header in requests and responses. A computer receiving the key identifiers may retrieve the secret keys and identify the symmetric encryption constructions in the selected AEAD pipeline.
[0041] According to another aspect, systems and quantum-resistant methods are provided for securely sharing secret keys for a selected AEAD pipeline. For example, in some embodiments, both a client computer and a server computer may store at least one securely shared Network Secret Salt Key, a mutually agreed hashing algorithm and key derivation function (KDF), and a collection of one or more key encapsulation mechanisms (KEMs). The KEM collection may comprise one KEM required by the server computer, and one KEM required by the client computer. The client computer may generate a public and private key pair and a unique symmetric key identifier using each KEM of the collection for each symmetric encryption construction of the selected AEAD pipeline. The client computer may compose a message comprising the public keys of the client computer and symmetric key identifiers. The client computer may derive indexed network secret keys using the KDF, a selected Network Secret Salt Key as input key material and information based on time and sequence as parameters to the KDF. In some embodiments, the client computer may generate a string of random bytes to use as salt for this request (Request Salt). The client computer may use the Request Salt as salt to the KDF when deriving the indexed network secret keys. The client computer may construct an associated request metadata object comprising encryption time, and the names of the symmetric encryption constructions of the selected AEAD pipeline. In some embodiments the associated request metadata may further comprise the Request Salt. The client computer may encrypt the message to obtain an encrypted message and authenticate associated request metadata with the selected AEAD pipeline, the indexed network secret keys, and unique nonces. The client computer may send the encrypted message and request headers to the server computer over a TLS-encrypted connection. The request headers may comprise the authenticated metadata, a unique request identifier, and authentication credentials required by the server computer. In some embodiments, the unique request identifier is a nonce or a collection of nonces used in the AEAD pipeline. The authenticated metadata may further comprise a request URL, and a HTTP method. The client computer may send a client certificate to the server computer to establish a TLS-encrypted connection.
[0042] Upon receiving the encrypted message and request headers over the TLS encrypted connection, the server computer may retrieve the names of symmetric encryption constructions of the selected AEAD pipeline. For each symmetric encryption construction in the selected AEAD pipeline, the server computer may derive indexed network secret keys using a selected KDF, a selected Network Secret Salt Key as input key material and information based on time and sequence as parameters to the KDF. In some embodiments, if the associated request metadata comprises a Request Salt, the server computer can use the received Request Salt as a salt parameter to the KDF when deriving the indexed network secret keys. The server computer may then authenticate and decrypt the encrypted message to get the request message with the selected AEAD pipeline and indexed network secret keys. For each symmetric encryption construction in the selected AEAD pipeline, the server computer may generate a pair of public and private keys using each KEM in the selected KEM collection, derive a shared secret using the private key of the server computer and the received public key of the client computer corresponding to the KEM, and concatenate the shared secrets in the sequence of KEMs in the collection to obtain an input key material. The server computer may derive a secret key for the symmetric encryption construction using the KDF, the input key material, and the selected Network Secret Salt Key as a parameter. The server computer may store the secret key and associate it with the symmetric encryption construction and the unique key identifier received from the client computer.
[0043] In response to the request, the server computer may compose a response message and associated response metadata. The response message may comprise the public keys of the server computer generated above. The associated response metadata may comprise encryption time and a unique request identifier included in the request. The server computer may authenticate the associated response metadata and encrypt the response message with the selected AEAD pipeline and the indexed network secret keys derived above to obtain an encrypted response message. The server computer may respond with the encrypted response message and response headers including the associated response metadata over the TLS-encrypted connection.
[0044] Upon receiving the encrypted response over the TLS-encrypted connection, the client computer may compare the unique request identifier received against the identifier sent in the request to detect tampering of the response. If the sent and received request identifiers match, the client computer may authenticate and decrypt the encrypted response message to obtain a response message with the selected AEAD pipeline and the indexed network secret keys. For each symmetric encryption construction of the selected AEAD pipeline, the client computer may derive a secret key using the private keys of the client computer and the public keys of the server computer included in the response message, using the same steps and KDF parameters as the server computer. The client computer may store the derived secret key and associate it with the symmetric encryption construction and the unique key identifier generated above. Upon failure to authenticate or decrypt the encrypted response message, the client computer can discard the response, and retry with a new request after a predefined interval.
[0045] According to another aspect, systems and quantum-resistant methods are provided for securely exchanging data and verifying data integrity by successfully authenticating and decrypting a multiply encrypted message in requests and responses. For example, in some embodiments, both a client computer and a server computer may store at least one pipeline of one or more symmetric encryption constructions, and at least one unique secret key for each symmetric encryption construction of the pipeline. The client computer may compose a request message and associated request metadata. The associated request metadata may comprise encryption time and one or more unique key identifiers. In some embodiments, the associated request metadata may further comprise a request URL, and a HTTP method. The client computer may encrypt the request message to obtain an encrypted message and authenticate the associated request metadata with a selected AEAD pipeline. Each symmetric encryption operation of the pipeline uses a recent secret key associated with the construction, and a unique nonce. The selected AEAD pipeline ends with an AEAD construction using a key size of at least 256 bits. In some embodiments, the associated request metadata may further comprise a string of random bytes generated by the client computer as salt for the request (Request Salt). The client computer may derive a new secret key for each symmetric encryption construction using a KDF, a stored recent secret key associated with the construction, and the Request Salt. The client computer may send the encrypted message and request headers to the server computer over a TLS-encrypted connection. The request headers may comprise the authenticated metadata, a unique request identifier, and authentication credentials required by the server computer. In some embodiments, the unique request identifier is a nonce or a collection of nonces used in the AEAD pipeline. In some embodiments, the client computer may send a client certificate to the server computer to establish a TLS-encrypted connection.
[0046] Upon receiving the encrypted message and request headers over the TLS encrypted connection, the server computer may compare the encryption time included in the associated request metadata against current time to detect replay attacks. The server computer may retrieve the secret keys associated with the key identifiers in the associated request metadata to identify the pipeline of symmetric encryption constructions. In some embodiments, if the associated request metadata comprises a Request Salt, the server computer may derive a new secret key for each construction in the selected AEAD pipeline using a selected KDF, the secret key associated with this construction, and the received Request Salt. The server computer may check to make sure the secret keys and received credentials belong to the same client. In some embodiments, the server computer may check the request URL and a HTTP method included in the associated request metadata against the current request's URL and HTTP method. The server computer may authenticate and decrypt the encrypted message to obtain a request message with the retrieved or derived secret keys, the received nonces, and the pipeline of symmetric encryption constructions in reverse order.
[0047] In response to the request, the server computer may compose a response message and associated response metadata. The associated response metadata may comprise encryption time, unique key identifiers, and a unique request identifier included in the request. The server computer may authenticate the associated response metadata and encrypt the response message with the selected AEAD pipeline and the retrieved or derived secret keys to obtain an encrypted response message. The server computer may respond with the encrypted response message and response headers including the associated response metadata over the TLS-encrypted connection.
[0048] Upon receiving the encrypted response over the TLS-encrypted connection, the client computer may compare the unique request identifier received against the identifier sent in the request to detect tampering of the response. If the sent and received request identifiers match, the client computer may authenticate and decrypt the encrypted response message to obtain a response message with the selected AEAD pipeline and the retrieved or derived secret keys. Upon failure to authenticate or decrypt the encrypted response message, the client computer can discard the response, and retry with a new request after a predefined interval.
[0049] In some embodiments, before encrypting with a selected AEAD pipeline, the request message or the response message may be prepended with random bytes, appended with random bytes, and concatenated with a first indicator of one or more bytes representing the number of bytes prepended, and a second indicator of one or more bytes representing the number of bytes appended. Both indicators can have the same length. The associated request metadata or the associated response metadata may further comprise the length of the first indicator. After decrypting with a selected AEAD pipeline, the receiving computer may discard the indicator bytes, prepended bytes and appended bytes to get the message.
[0050] According to another aspect, a cyber security and information management system is provided to securely manage information, match and exchange data, and to protect the APIs it provides and consumes. Preferably, the system only serves and accepts data encrypted with a selected AEAD pipeline and transmitted over TLS encrypted connection, except when it pulls data from a third party data source that does not support multiple encryption. It may enable decentralised organisations to share private or confidential information in a quantum-resistant way across jurisdictions. In this manner it may be a universal adaptor of decentralised disparate systems and a common data exchange interface for counterpart regulators under an MRA.
[0051] In some embodiments, reference is made with the term "FORMR" (FOR Mutual Recognition) in the specification to describe how the embodiments work. In this aspect of the invention, each regulator runs its own computer network, and these computer networks form a secure network (FORMR Network) to match and exchange information between regulators.
[0052] In some embodiments, the computer networks may comprise a multitude of containerised computer processes running in a Kubernetes cluster of physical servers or virtual private servers (VPS), and purposefully built client applications running on user devices to access and manage information securely.
[0053] In some embodiments, the server computer can be deployed in situ or in one or more data centres chosen by the regulator. If it is deployed in a data centre, a reverse proxy server component can be deployed in situ, encrypting data for transit and authenticating requests to pull data from a regulator's on-premise registration/compliance systems.
[0054] Kubernetes is the preferred technology to build the underlying cluster to run an embodiment, although it is also possible to build a cluster with other technologies supporting Open Container Initiative (OCI) specifications, such as Docker Swarm or
Cloud Foundry. Kubernetes is preferred as it allows low level control of container images and container runtime including role-based access control (RBAC) and security context, which are important to limit runtime privileges and manage cyber security risks. There are more tools and technicians available to manage Kubernetes clusters.
Brief Description of the Drawings
[0055] Notwithstanding any other forms which may fall within the scope of the present disclosure, preferred embodiments of the invention will now be described, by way of ex ample only, with reference to the accompanying drawings in which:
[0056] FIG 1A illustrates deployment scenarios, a FORMR Network and increased cyber threats according to some embodiments;
[0057] FIG 1B illustrates a remote deployment and on-premise connector with mutual authentication according to some embodiments;
[0058] FIG 2 illustrates the combined BGP/DNS monitoring and information flow between systems according to some embodiments;
[0059] FIG 3 illustrates the process of pulling information from legacy systems according to some embodiments;
[0060] FIG 4A illustrates the login process of web hosts requiring a client certificate according to some embodiments;
[0061] FIG 4B illustrates the access control of web hosts requiring a client certificate according to some embodiments;
[0062] FIG 5 illustrates the access control of web hosts without CCA according to some embodiments;
[0063] FIG 6A illustrates the process of sharing personal information on a client computer according to some embodiments;
[0064] FIG 6B illustrates the process of registered and authenticated workers voluntarily sharing personal information with employers and another regulator across jurisdiction according to some embodiments;
[0065] FIG 7 illustrates the process of pushing information to another embodiment according to some embodiments;
[0066] FIG 8 illustrates the process of receiving information from another embodiment according to some embodiments;
[0067] FIG 9 illustrates the process of one regulator requesting cross-jurisdiction information according to some embodiments;
[0068] FIG 10 illustrates the process of supplying requested information to another regulator across jurisdiction according to some embodiments; and
[0069] FIG 11 illustrates the reference deployment with high availability and cluster monitoring according to some embodiments.
Description of Embodiments
Overview
[0070] To avoid lengthy negotiations, two computers, for example, a client computer and a server computer, requiring different encryption constructions may compose a pipeline comprising these constructions for both computers to meet the requirements. The pipeline ends with an AEAD construction. A key size for the AEAD construction may be at least 256 bits. If neither of these two constructions satisfies this requirement, the pipeline can further comprise a third symmetric encryption construction which is a cryptographically strong AEAD construction with a key size of for example 256 bits. In some embodiments, the pipeline may consist of just one AEAD construction accepted by both computers. The pipeline of one or more symmetric encryption operations may provide 128 bits of protection against quantum computers, even if the quantum computers can break asymmetric algorithms used for key exchanges in TLS encryptions in the future.
[0071] To mitigate the risks of vulnerability to timing attacks due to a lack of hardware acceleration or implementation errors, the client computer and the server computer can use dynamic encryption keys for the pipeline in each request and response. The client computer can generate a string of random bytes as salt for each request, and derive dynamic encryption keys using the salt and the pre-shared secrets, such that each request uses different encryption keys. This may greatly reduce the risk of nonce collision. The client computer may perform cascades of encryption operations in the order of the encryption constructions in the pipeline to obtain an encrypted request message, and authenticate associated request metadata which comprises the request salt. The client computer may send a request to the server computer over a TLS-encrypted connection. The request may comprise the encrypted request message and request headers which include the associated request metadata, a unique request identifier generated by the client computer, unique secret key identifiers, and credentials required by the server computer. The encrypted request message will remain confidential if it is sent to an impersonated server computer, though the credentials included in request headers could still be stolen during internet hijacking.
[0072] To detect stolen credentials and prevent unauthorised access, the server computer can attempt to authenticate and decrypt the encrypted request message in the reverse order of the pipeline, and deny access on failure to authenticate or failure to decrypt. The server computer may derive dynamic secret keys using the received request salt and pre-shared secrets associated with the secret key identifiers. The server computer may grant access after successfully decrypting the encrypted request message and verifying the credentials. In response to the request, the server computer can encrypt the response message with the pipeline and the dynamic encryption keys to obtain an encrypted response message, and include the unique request identifier received from the client computer in the associated response metadata. The server computer may reply with a response over the TLS-encrypted connection. The response may comprise the encrypted response message and response headers including the associated response metadata.
[0073] To verify the integrity of the response and detect tampering, the client computer may attempt to authenticate and decrypt the encrypted response message in the reverse order of the pipeline. After successfully decrypting the encrypted response message and verifying the received request identifier against the sent request identifier, the client computer may accept the response. The client computer may discard the response upon failure to authenticate or failure to decrypt the encrypted response message, and retry with a new request after a predefined interval.
[0074] The client computer may exchange public keys to derive shared secrets with the server computer using the above steps and treating the public keys as a message. By verifying a response with the pipeline of decryption, the client computer prevents accepting public keys received from an impersonated server computer during internet hijacking. Encrypting the public keys with a pipeline of one or more constructions makes the key exchange process quantum-resistant regardless of algorithms used for the key exchanges.
[0075] The client computer and the server computer in the present disclosure may consistently enforce encrypted message using one or more symmetric encryption constructions in a pipeline, and use it together with mutual TLS to protect APIs that the client computer and the server computer provide and the internal APIs that the client computer and the server computer consume. Transmitting symmetrically encrypted data over a TLS-encrypted connection provides strong protection of data in transit. In addition, an encrypted message can be used by a client computer to verify the integrity of a received response. A pipeline of one or more encryption complements mutual TLS which alone does not protect data confidentiality or integrity when data is sent to a fake server during internet hijacking. Mutual TLS mitigates the risk of various attacks against symmetric encryption keys as attackers need a valid client certificate to connect to a computer. A pipeline of one or more encryption, mutual TLS and authentication credentials work together to achieve the goals of cyber security - confidentiality, integrity and availability.
[0076] In some embodiments, to protect the integrity of data in a network, some computers may exchange authenticated and symmetrically encrypted data only with other computers and other systems over a TLS-encrypted connection, and may reject plaintext data submitted by other systems. Such embodiments may monitor BGP/DNS status, and pull data from the source only when it is secure to do so. With a combination of these methods, these embodiments can protect data confidentiality and integrity of all regulators under an MRA under all circumstances, even when symmetrically encrypted data and plaintext credentials are inevitably sent to a fake server during incidents of internet hijacking.
[0077] The security of a FORMR Network is based on a securely shared Network Secret Salt Key. The Network Secret Salt Key is used as input key material to derive symmetric encryption keys for authentication in the network. It is also used as a salt parameter to a KDF to randomise derived secret keys after exchanging public keys with another computer. This is explained in detail in the security model section later in the specification. In some embodiments, computers may use quantum-resistant key exchange algorithms to derive secret keys, and use cryptographically strong symmetric encryption to securely distribute shared secrets. A daily network secret can be derived from the Network Secret Salt Key in a FORMR Network. A web host may be publicly accessible without a client certificate, but validate API requests with the daily network secret. A new computer may share/derive a secret with any existing computer in the FORMR Network in a quantum resistant way, use the shared secret to obtain the Network Secret Salt Key, and then derive the network secret as authentication to obtain client certificate and derive shared secrets with other computers in the network.
[0078] An present disclosure can be deployed on premise or in a data centre. When it is deployed in a data centre and pulls data from registration/compliance systems on premise, as illustrated in FIG 1B, there are the fewest changes to a regulator's current workflow. In this deployment scenario, a client computer may connect to an on-premise reverse proxy server behind a regulator's firewall, over HTTPS and mutual authentication, and fetch authenticated symmetrically encrypted data. The reverse proxy server may keep API credentials, connect to the registration/compliance systems over the local area network to fetch data, and encrypt data with a shared secret key before responding to the client computer in a remote data centre. The reverse proxy server can demand a valid client certificate before establishing a HTTPS connection, and can validate web requests by decrypting requests with a secret key shared with the client computer. The registration/compliant systems' API credentials may stay on the premise. The client certificate, private key for mutual authentication and the shared secret can be encrypted at rest, and be available to the client computer at runtime only. For as long as the secrets are kept secure, mutual authentication can protect systems against brute-force attacks and exploits of published and undisclosed vulnerabilities. A configurable client certificate signed with a regulator's private CA key can provide the same protection for mutual authentication and is recommended for easier CA key rotation, and less reliance on third parties for cyber security. Even though the registration/compliance systems are accessed from the outside, this method can be effective in protecting data confidentiality, and can avoid pushing data and credentials to a fake server during incidents of internet hijacking. A regulator has more controls over the API protocols. A web client should have both the private key of the signed client certificate and the shared secret to read data from the registration/compliance systems, within the permissions granted. As long as the computer network is kept secure, the registration/compliance systems will be secure.
[0079] An alternative to the above described pulling approach is to build a custom client application to read data locally from registration/compliance systems, encrypt data with a shared secret key, and push to an server computer along with a client certificate and API credentials. This approach is likely to be much more expensive, time consuming, and may not be feasible in some cases if the registration/compliance systems use legacy closed-source software and proprietary data storage format.
Terminologies
[0080] Before discussing embodiments of the invention, description of some terms may be helpful in understanding the various embodiments.
[0081] The term "server computer" may include a computer, or cluster of computers, or a group of servers or web services functioning as a unit. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers. A server computer may perform the methods of a client computer described in this specification when it communicates with another server computer.
[0082] The term "symmetric encryption construction" may refer to an encryption construction that uses the same secret key and nonce to encrypt and decrypt data. A construction may use a block cipher or a stream cipher, a selected mode of operation, a selected key size, a selected nonce size, and a selected tag size if the construction includes authentication. The construction may include specifications of concatenating the encrypted message and authentication tag or nonce.
[0083] The term "AEAD construction" may refer to an authenticated encryption with associated data (AEAD) construction, which is a subset of symmetric encryption constructions. In an AEAD construction, associated data is authenticated but not encrypted.
[0084] The term "secret key" may refer to a shared secret for use in a symmetric encryption construction. The secret key can be used directly, or be used to derive new secret keys. Each secret key is associated with one symmetric encryption construction only.
[0085] The term "AEAD pipeline" may refer to an ordered set of one or more symmetric encryption constructions, with the ending construction being an AEAD construction. Encryption and decryption operations in an AEAD pipeline are performed sequentially, with each operation cascading the output to the subsequent operation. Decryption operations are performed in the reverse order of the ordered set. The ciphertext output of an AEAD pipeline may be transmitted over a TLS-encrypted connection. The AEAD pipeline does not count any construction used in the TLS encryption, though it may include an identical construction with a different encryption key.
[0086] The term "request salt" may refer to a sequence of bytes generated by a client computer using a pseudo random number generator, and included in a request to a server computer. Both a client computer and a server computer may derive a new secret key for each request/response cycle using a pre-shared secret key and the request salt.
[0087] The term "request identifier" may refer to a unique identifier for each request generated by a client computer and sent along in the request. A server computer may include a request identifier received from a client computer in the associated response metadata. The client computer may verify the integrity of a response by authenticating the associated response metadata with a selected AEAD pipeline and comparing the echoed request identifier against the request identifier sent to the server computer.
[0088] The term "associated request metadata" may refer to the data associated with a request message and authenticated with a selected AEAD pipeline. For example, associated request metadata may comprise encryption time, secret key identifiers, request salt, and nonces used in encryption. It is typically included as a header in a request from a client computer.
[0089] The term "associated response metadata" may refer to the data associated with a response message and authenticated with a selected AEAD pipeline. It is typically included as a header in a response from a server computer.
[0090] The term "message" may refer to the actual payload data transmitted in a request or response. Typically a message or payload is the body of the request or response, which may include one or more headers. When a message is encrypted, the encrypted message may be concatenated with authentication information, also referred to as an authentication tag, and may further be encoded in base64 format, and the base64 encoded text becomes the body of the request or response. In this specification, the term "message" is used interchangeably with the term "data", unless the context indicates otherwise.
[0091] The term "network secret salt key" may refer to a master secret key pre-shared among computers belonging to a network. The network secret salt key can be used as a master secret key to derive other secret keys to authenticate with other computers in the network, and be used to derive salt to randomise derived secret keys after a key exchange between computers.
[0092] The term "FORMR Network" may refer to a network of server computers sharing a network secret salt key and agreeing to a communication protocol. For example, a server computer may authenticate requests from other server computers by authenticating and decrypting encrypted messages with a selected AEAD pipeline and encryption keys derived from the network secret salt key and dynamic information included in the request. The network secret salt key is shared with server computers in the network only.
[0093] The term "multiple encryption" may refer to encrypting data with a selected AEAD pipeline of one or more symmetric encryption constructions, and encrypting the encrypted data and HTTP headers one more time with TLS encryption.
Embodiments
[0094] The present invention is a combined cyber security and information management system to share private or confidential information between decentralised organisations such as regulators from different jurisdictions under an MRA. The present invention may be referred to as FORMR in the present disclosure for easy reference.
[0095] In an embodiment, a computer-implemented method is disclosed for a client computer to securely exchange data with a server computer. The method is performed by the client computer. The client computer stores a client AEAD pipeline comprising a symmetric encryption construction required by the server computer, a symmetric encryption construction required by the client computer. The client AEAD pipeline also ends with a client authenticated encryption with associated data (AEAD) construction. The client computer further stores a client secret key associated with each encryption construction of the client AEAD pipeline. Each client secret key is identified by a client key identifier and is securely shared between the server computer and the client computer. The way of sharing the secret key is also described in the present disclosure.
[0096] The client computer initiates a request of multiple encryption to the server computer. The request comprises a first request identifier identifying the request, request ciphertext representing request payload, request metadata, and request authentication information. The request ciphertext is generated by encrypting the request payload with each of the encryption constructions in the client AEAD pipeline. The request metadata is associated with the request payload and includes each client key identifier for the client AEAD pipeline. The request authentication information, also referred to as an authentication tag in the present disclosure, authenticates the request ciphertext and the request metadata. The request authentication information or the authentication tag is generated with the client secret key for the client AEAD encryption construction of the client AEAD pipeline.
[0097] The client computer further encrypts the request with a Transport Layer Security (TLS) protocol and transmits the request to the server computer. Upon receipt of the request from the client computer, the server computer process the request and send a response to the client computer. The way of the server computer processing the requests and constructs the response will also be described in detail in the present disclosure.
[0098] The client computer receives the response to the request of multiple encryption from the server computer. The response is encrypted with the TLS protocol. The client computer decrypts the response with the TLS protocol to obtain response ciphertext representing response payload, response metadata, and response authentication information.
[0099] The response metadata is associated with the response payload. The response metadata comprises a second request identifier and each server key identifier identifying each server secret key for a server AEAD pipeline. The server AEAD pipeline includes the symmetric encryption construction required by the server computer, the symmetric encryption construction required by the client computer, and ends with a server AEAD construction.
[0100] The client computer extracts the second request identifier from the response metadata, and compares the second request identifier with the first request identifier.
[0101] If the second request identifier matches the first request identifier, the client computer retrieves each server key identifier for the server AEAD pipeline from the response metadata. The client then obtains each server secret key for the server AEAD pipeline and identifies each encryption construction of the server AEAD pipeline corresponding to each server key identifier.
[0102] The client computer successfully authenticates the response ciphertext and the response metadata with the response authentication information using the server AEAD construction of the server AEAD pipeline and the server secret key for the server AEAD construction of the server AEAD pipeline, the client computer decrypts the response ciphertext with the server AEAD pipeline to obtain the response payload.
[0103] In another embodiment, a computer-implemented method is disclosed for a server computer to securely exchange data with a client computer. The method is performed by the server computer.
[0104] Specifically, the server computer stores a server AEAD pipeline. The server AEAD comprises the symmetric encryption construction required by the server computer, the symmetric encryption construction required by the client computer. The server AEAD pipeline ends with a server authenticated encryption with associated data (AEAD) construction.
[0105] The server computer further stores a server secret key associated with each encryption construction of the server AEAD pipeline. Each server secret key is identified by a server key identifier and is securely shared between the server computer and the client computer.
[0106] As described above, the client computer sends the request of multiple encryption to the server computer, and the server computer receives the request from the client computer encrypted with the Transport Layer Security (TLS) protocol.
[0107] The server computer decrypts the request with the TLS protocol to obtain a request identifier, which is the first request identifier, the request ciphertext representing the request payload, the request metadata associated with the request payload, and the request authentication information authenticating the request ciphertext and the request metadata. As described above, the request metadata comprises each client key identifier for the client AEAD pipeline.
[0108] The server computer retrieves each client secret key with each client key identifier, and identifies each encryption construction of the client AEAD pipeline according to each client key identifier or each client secret key.
[0109] If server computer successfully authenticates the request ciphertext and the request metadata with the request authentication information, the server computer decrypts the request ciphertext with the client AEAD pipeline to obtain the request payload. Based on the request payload, the server computer generate response payload which may include information as requested in the request payload.
[0110] The server computer replies to the client computer with a response. The response comprises response ciphertext representing the response payload, response metadata associated with the response payload, and response authentication information. The response metadata comprises the request identifier and each server key identifier for the server AEAD pipeline. The response authentication information authenticates the response ciphertext and the response metadata with the server AEAD construction of the server AEAD pipeline. The response ciphertext is a result of encrypting the response payload with the sever AEAD pipeline. The response is also encrypted with the TLS protocol.
[0111] As described above, even if the server is a fake server and the client computer provides the client credentials to the fake server, which may decrypt the request with the TLS protocol, the fake server is not able to decrypt the request ciphertext in order to obtain the request payload. This is because the fake server does not know each client secret key for the client AEAD pipeline, which is required to decrypt the request ciphertext. As a result, the fake server is not able to provide the appropriate response payload corresponding to the request payload.
[0112] Further, even if the fake server happens to successfully guess the request payload without decrypting the request ciphertext and is able to provide the appropriate response payload, the fake sever can only generate inappropriate response authentication information to authenticate the response ciphertext and the response metadata because the fake server does not know the appropriate server secret key for the server AEAD construction of the server AEAD pipeline, in spite of the fact that the fake server may provide each server key identifier of the server AEAD pipeline in the response metadata.
[0113] When the client computer receives the response, the client computer decrypts the response with the TLS protocol to obtain the response ciphertext, the response metadata, and the response authentication information. The client computer will try to identify each server secret key according to each server key identifier provided in the response metadata. The client computer will either fail to identify any server secret key or identity the wrong server secret key, particularly, the server secret key for the server AEAD construction of the server AEAD pipeline. As a result, the client computer is not able to authenticate the response ciphertext and the response metadata with the response authentication information. This means that the response is sent from a fake server.
[0114] In a further embodiment, a computer-implemented method is disclosed for a client computer to securely share secret keys with a server computer.
[0115] The client computer stores an AEAD pipeline comprising a symmetric encryption construction required by the server computer, a symmetric encryption construction required by the client computer. The AEAD pipeline ends with a client AEAD construction.
[0116] The client computer stores a Network Secret Salt Key securely shared between the client computer and the server computer, and also stores a hashing algorithm for both the client computer and the server computer.
[0117] The client computer stores a collection of key encapsulation mechanisms (KEM). The KEM collection comprises a client KEM required by the client computer and a server KEM required by the server computer.
[0118] For each encryption construction of the AEAD pipeline, the client computer generates a pair of client private and public keys with each KEM in the collection of KEMs.
[0119] The client computer derives an indexed secret key using a key derivation function (KDF) and the hashing algorithm for each encryption construction of the AEAD pipeline. Parameters of the KDF include the Network Secret Salt Key as input key material, and a string comprising an exchange time and a sequence number indicating a symmetric encryption construction in the AEAD pipeline.
[0120] The client computer encrypts request payload with each indexed secret key for the AEAD pipeline to obtain request ciphertext representing the request payload. The request payload comprises each client public key for the collection of KEMs.
[0121] The client computer generates request authentication information authenticating the request ciphertext based on the AEAD encryption construction of the AEAD pipeline.
[0122] The client computer initiates a request to the server computer. The request comprises a first request identifier, the request ciphertext representing the request payload, and the request authentication information. The request is encrypted with a TLS protocol and sent to the server computer.
[0123] Upon receipt of the request at the server computer, the server computer processes the request and sends a response to the client computer. The way of the server computer processing the request will also be described in detail in the present disclosure.
[0124] The client computer receives the response from the server computer and decrypts the response with the TLS protocol to obtain response ciphertext representing response payload, response metadata comprising a second request identifier, and response authentication information authenticating the response ciphertext and the response metadata.
[0125] The client computer compares the first request identifier with the second request identifier.
[0126] if the second request identifier matches the first request identifier, and the client computer successfully authenticates the response ciphertext and the response metadata with the response authentication information based on the indexed secret key for the AEAD construction of the AEAD pipeline, the client computer decrypts the response ciphertext with each indexed secret key for the AEAD pipeline to obtain the response payload.
[0127] The client computer further parses the response payload to obtain a collection of server public keys; and derives input key material of the KDF from the collection of server public keys and each client private key.
[0128] The client computer further derives a shared secret key for each encryption construction in the AEAD pipeline using the KDF and the hashing algorithm with the Network Secret Salt Key as salt of the KDF.
[0129] In a further embodiment, a computer-implemented method is disclosed for a server computer to securely share secret keys with a client computer.
[0130] The server computer stores an AEAD pipeline. The AEAD pipeline comprises a symmetric encryption construction required by the server computer, a symmetric encryption construction required by the client computer. The AEAD pipeline ends with a client authenticated encryption with associated data (AEAD) construction.
[0131] The server computer stores a Network Secret Salt Key securely shared between the client computer and the server computer and stores a hashing algorithm for both the client computer and the server computer.
[0132] The server computer stores a collection of key encapsulation mechanisms (KEM). The KEM collection comprises a client KEM required by the client computer, and a server KEM required by the server computer.
[0133] The server computer receives the request from the client computer and the request is encrypted with a TLS protocol.
[0134] The server computer decrypts the request with the TLS protocol to obtain request identifier, request ciphertext representing the request payload, and the request authentication information authenticating the request ciphertext.
[0135] The server computer further identifies each encryption construction in the AEAD pipeline, and derives an indexed secret key using a key derivation function (KDF) and the hashing algorithm for each encryption construction in the AEAD pipeline. Parameters of the KDF include the Network Secret Salt Key as input key material of the KDF, and a string comprising an exchange time and a sequence number indicating the encryption construction in the AEAD pipeline.
[0136] If the server computer successfully authenticates the request ciphertext with the request authentication information, the server computer decrypts the request ciphertext to obtain the request payload with the AEAD pipeline using each indexed secret key.
[0137] The server computer then parses the request payload to obtain a collection of client public keys.
[0138] For each encryption construction in the AEAD pipeline, the server computer generates a pair of server private and public keys with each KEM in the KEM collection.
[0139] The server computer derives input key material of the KDF from the collection of server private keys and each client public key.
[0140] The server computer derives a shared secret keyforeach encryption construction in the AEAD pipeline using the KDF and the hashing algorithm with the Network Secret Salt Key as salt of the KDF.
[0141] The server computer constructs response metadata comprising the request identifier.
[0142] The server computer encrypts response payload to obtain response ciphertext with the AEAD pipeline using each indexed secret key. The response payload comprises each server public key generated with the KEM collection.
[0143] The server computer generates response authentication information authenticating the response ciphertext and the response metadata, and responds to the client computer with a response comprising the response ciphertext, the response metadata, and the response authentication information. The response is encrypted with the TLS protocol and sent to the client computer.
[0144] Further details of the methods and systems are described below.
Vulnerabilities of dynamically negotiated secret keys during internet hijacking
[0145] As explained above, in a typical data exchange between a web server (API provider) and clients (API consumers), the server dictates the API protocols in authentication and data formats, and the clients initiates the requests. When a client establishes a HTTPS connection to a web server and the server can provide a valid SSL/TLS certificate, the client would submit authentication credentials and data by encrypting the communication with a dynamically negotiated secret key with the server's public key. The server has the negotiated secret key, and can decrypt the communication and access the credentials and data.
[0146] During incidents of internet hijacking, an attacker may tamper with the DNS resolution or IP address routing of a web service, and set up a fake server to receive such authentication credentials and data from a remote location. Some web clients will inevitably send requests to the fake server, depending on which ISP networks the web clients are connected to and which DNS server the web clients use. Some web clients may not be affected. Terminating all sessions and rotating API credentials do not resolve all issues. Security model to mitigate risks of stolen data and credentials and malicious responses from an impersonated server
[0147] The cyber security model of a FORMR Network is based on a Network Secret Salt Key of random bytes securely shared in the FORMR network. The client computer and the server computer in the FORMR network may authenticate each other by encrypting, authenticating and decrypting encrypted messages with an AEAD pipeline in both requests and responses. The encrypted messages may be transmitted over a TLS encrypted connection.
[0148] A Network Secret Salt Key can be used as the salt parameter to a key derivation function (KDF) such as HMAC-based key derivation function (HKDF) to protect the security of the secret keys when client computer and the server computer derive secret keys from the same key materials shared over the internet. A Network Secret Salt Key can also be used as input key material to derive daily network secrets and indexed network secret keys for authentication and encryption in a FORMR Network. A Network Secret Salt Key must be kept secure and should be long enough to provide resistance to cyber-attacks. For example, the Network Secret Salt Key is at least 256 bits (32 bytes) long, and preferably 512 bits (64 bytes) or longer. The length of 512 bits is recommended to provide strong 256-bit resistance to brute-force attacks by a quantum computer, and to use as salt directly when a HKDF operation uses the hashing algorithm SHA-512 which requires a 512-bit key. Some FORMR Networks may share a master secret key and a separate salt for use in the network. Using a master secret key as salt may help keep the salt a secret.
[0149] Regarding the secrecy of the Network Secret Salt Key, readers should ignore the prevailing statements on the internet contradictory to this critical requirement, such as "salt does not need to be kept secret". Though such statements do not exclude keeping salt as a secret, a casual reading of such statements may cause the salt to be improperly handled in one or more embodiments, and may thus jeopardise the security of the whole network. IETF RFC 5869, the HKDF author's original paper, and the documentation of some cryptography libraries/APIs were written for a different context (if missing, the salt of a HKDF function may default to null bytes which is not a secret), and not for quantum resistant cyber security. In case the shared key materials are compromised (e.g. by a powerful quantum computer in the future or an exploitation of pseudo random number generators), the Network Secret Salt Key and a strong HMAC algorithm may still protect the confidentiality of secret keys. Common letters, digits, and cryptic symbols entered on a keyboard may use only 7 out of 8 bits in an octet and may have repeating patterns. Human readable pass phrases, even long and complex, may not meet this requirement.
[0150] A Network Secret Salt Key should never be transmitted, viewed, or entered in plaintext over the internet unless the communications are quantum-resistant. Most popular asymmetric algorithms currently in use rely on one of three difficult mathematical problems: the integer factorisation problem, the discrete logarithm problem or the elliptic curve discrete logarithm problem. An adversary can efficiently solve all three problems with a powerful quantum computer running Shor's algorithm. Asymmetric algorithms (ECDSA, ECDH) in popular protocols such as HTTPS, SSH, TLS, S/MIME, OpenPGP, IPsec etc are not quantum-resistant. These algorithms may still be used for backward compatibility during the transition to quantum-resistant algorithms. If the Network Secret Salt Key is transmitted using these protocols, and an adversary records all traffic between two computers, the adversary may be able to decrypt transmissions in the future and gain access to key materials and encrypted contents including the Network Secret Salt Key.
[0151] To be future-proof, for embodiments deployed in a data centre, a Network Secret Salt Key should be entered using a client application over a secure connection, or derived on the server with a quantum-resistant Key Encapsulation Mechanisms (KEM) in standalone or hybrid mode. If a Network Secret Salt Key is derived, a HKDF implementation as defined in IETF RFC 5869 and a cryptographically strong HMAC algorithm (eg HMAC-SHA-384) should be used. SHA-384 is one of the hashing algorithms resistant to length extension attacks. The private keys for a key exchange should never be transmitted, viewed or downloaded over the internet. A compromise of the private keys will compromise the security of the Network Secret Salt Key.
[0152] In two embodiments both deployed on premise, random bytes may be generated as a Network Secret Salt Key, share it through an established secure quantum-resistant channel and entered from a device on premise. Alternatively, a Network Secret Salt Key may be derived with a HKDF function and a strong HMAC algorithm (e.g., HMAC-SHA 384) using a shared key material and optional salt to avoid transmitting or transporting the Network Secret Salt Key. Then the key material and salt should have been shared using a secure quantum-resistant channel. It is recommended to use a hybrid of ECDH and quantum-resistant KEM algorithms to exchange public keys and derive key materials.
[0153] Embodiments may be managed with a purposely built client application, or using quantum-resistant protocols from virus-free devices. The details of key exchange and derivation are explained later in the specification.
[0154] Computers may use a combination of encryption with an AEAD pipeline using pre shared secrets and multi-factor authentication of API among others to protect data confidentiality and integrity under all circumstances. In some networks, all computers may only exchange data encrypted with an AEAD pipeline with other computers and client applications. Endpoints intended for users of high privileges should be protected with client certificates and are referred to as mTLS Endpoints. Some endpoints are intended for stakeholders (eg registered workers) or for other computers to request a client certificate, and are referred to as TLS Endpoints in this specification. A separate hostname may be required to serve contents over TLS endpoints, because some reverse proxy servers (such as Nginx) require a client certificate for all routes once CCA is enabled for a hostname.
[0155] In an embodiment, data or token encrypted with an AEAD pipeline may be used as a factor to make sure a request is actually from a genuine web client in possession of a shared secret, not from an attacker using stolen credentials. During incidents of internet hijacking, both ciphertext and credentials could be stolen from victimised web clients. Computers should not serve data in plaintext (the request could have come from an attacker using stolen credentials). Computers should not accept data in plaintext pushed here from the internet (the data could have been forged by an attacker and sent here with stolen credentials). A computer may reject the request if it cannot decrypt the data with the secret key shared with the client, or the allowed time window has elapsed. It may suspend the API keys and the associated client certificates in case of repeated decryption failures, which is a sign of timing attacks with a stolen certificate and API key.
[0156] Under any circumstances, a computer should not disable the mutual authentication or the validation of multiple encryption to accept data in plaintext or ciphertext using a weak algorithm/mode (eg ECB) pushed here over the internet with or without TLS encryption. This loophole is convenient, but may jeopardise data confidentiality and integrity of all regulators in the FORMR Network. As explained above, data in plaintext or encrypted with a weak algorithm/mode intended for an client computer may be sent to a fake server, along with credentials, during incidents of internet hijacking, even if a TLS-encrypted connection is used.
[0157] When a computer acts as a client to pull data from a source over the internet, it should monitor BGP/DNS status, and submit authentication credentials only when the monitoring results are normal. In particular, computers achieve data confidentiality and integrity in the following ways: • precaution should be taken to avoid sending credentials to a fake server when pulling data. • Computers should not push plaintext data to anywhere. This may eliminate the possibility of sending plaintext data over HTTPS connection to a fake server. • When data is inevitably sent to a fake server in incidents of internet hijacking, the data may still be protected by encryption with a selected AEAD pipeline. • client computers need to be authenticated with multiple encryption along with credentials. When credentials are inevitably sent to a fake server in incidents of internet hijacking, an attacker may download symmetrically encrypted data from endpoints not protected by mutual authentication, but the attacker may not have access to the plaintext data. An attacker may not be able to tamper with data in the information system either with the stolen credentials.
Methods to negotiate symmetric encryption constructions and encoding for interoperability
[0158] Authenticating with multiple encryption in API protocols may be critical to the cyber security of a FORMR network. All computers should follow multiple encryption in this specification and transmit data encrypted with an AEAD pipeline over a TLS-encrypted connection. An AEAD pipeline is between a client computer and a server computer. The client computer may use an AEAD pipeline with a server computer, and may use a different AEAD pipeline with another server computer.
[0159] When encrypting data with a selected AEAD pipeline, each encryption operation may use a unique pre-shared secret key, a unique nonce (number used once), and may authenticate the same metadata. Encryption operations in the same pipeline may not share secret keys with another operation. An AEAD operation encrypts the data, authenticates the ciphertext and the metadata, and protects against tampering. For interoperability, an authenticated encryption operation may append an authentication tag to the ciphertext, and include the nonces in the authenticated metadata. The tag size should be kept at the maximum size allowed under that construction (typically 16 bytes) as truncated tags may lead to vulnerabilities.
[0160] An AEAD pipeline may be necessary if the client computer and the server computer belong to regulators from different jurisdictions which require different encryption constructions. For example, assuming due to compliance requirements in handling confidential/sensitive information, the client computer uses the algorithm AES (standardised by NIST), and the server computer uses Camellia (approved for use by CRYPTREC in Japan and ISO/IEC). An AEAD pipeline may include a construction using AES and another construction using Camellia. It should always end with an AEAD construction, which could be one of the required constructions already included, or a third AEAD construction. Both computers can start to exchange data and stay in compliance, without a lengthy process for the two jurisdictions to negotiate and agree on one construction. In case the data is stolen, it will still be protected by one or more of the encryptions.
[0161] An AEAD pipeline may increase the difficulty of brute-force attack against stolen ciphertext with quantum computers in the future. The output of a symmetric encryption construction may look just like random bytes. In case a secret key is discovered in a timing attack, assuming the second key is not vulnerable to the same timing attack, the information is still protected by the second key against brute-force attacks using Grover's algorithm and powerful quantum computers. Grover's algorithm (aka quantum search algorithm) suggests that it is possible with 50% probability to brute-force a 256-bit secret key by 2128 iterations (the square root of the total 2211 possibilities) to find a specific output. A variant divide-and-conquer algorithm, quantum partial search, may be faster by a numerical factor. Iterations of this magnitude are still impossible now. A pipeline of 2 constructions with 256-bit keys, with at least one construction resistant to timing attacks, will be more robust against a powerful adversary.
[0162] However quantum computing will likely be a threat to encryptions with 128-bit or shorter keys. Using the same quantum search algorithm above, to brute-force a 128-bit key, only 24 iterations will be required. This may become feasible to a resourceful adversary with the advancement of technology.
[0163] A quantum search performs unstructured search by measuring the state of quantum bits to look for a specific output. It can solve a blackbox function y = f(x) given the specific output y and the length of x. An AEAD pipeline of 3 constructions will make a blackbox function y = f(kl, k2, k3). It may take much longer time to discover a combination of 3 keys to be able to decrypt the output from the pipeline. This is why constructions in the same AEAD pipeline should never share secret keys. If an officially approved algorithm should be used but only supports 128-bit keys now, the AEAD pipeline of one or more subsequent constructions using 256-bit keys may provide the same protection as 256-bit keys. It may take years to develop and test a new encryption algorithm with longer keys before it is officially approved. An AEAD pipeline provides a future-proof solution now. The more imminent threat to symmetric encryption may come from timing attacks.
[0164] An AEAD pipeline should always end with one AEAD construction. For simplicity and interoperability, the same metadata should be used in each operation. If there are multiple operations in the pipeline, the nonces for all operations can be generated and included in the metadata before the first encryption operation. The output of one operation (encrypted message + tag) will be the input of the next operation as byte sequence. Each operation may use a different key with the maximum length of bits allowed under that algorithm. For AES and Camellia, the keys should be at least 256 bits. A secret key shared with another computer should have the same identifier. When a computer encrypts a message with a shared secret key, the recipient computer should be able to retrieve the construction associated with the key and decrypt the message. With a sequence of key identifiers and nonces, the recipient computer should be able to decrypt the message with the associated operations.
[0165] A unique nonce is may also be used for the security of symmetric encryption. In some protocols, a nonce is known as Initialisation Vector (IV). Nonces can be transmitted in plaintext, but may not be reused. Reusing a nonce may compromise all messages encrypted with the same key and nonce pair. In a distributed computing environment, maintaining a counter may cause extra complexity. Therefore, a nonce of 192 bits (24 bytes) is recommended so that random nonces can be safely used. Some constructions only support a nonce of 96 bits. In this case the keys should be rotated regularly (e.g., daily or hourly) depending on the frequency of data exchange. An embodiment should provide a configurable frequency to rotate keys automatically.
[0166] In some embodiments, both a client computer and a server computer can derive a new secret key for each request using a KDF, a request salt and shared secret keys. This may be an effective strategy to mitigate the risks of timing attacks and nonce collision. For interoperability and easy implementation, the derived secret keys can be used by the server computer in response to the request. An adversary may submit the same salt repeatedly to force an embodiment to use the same derived keys in a timing attack. Embodiments can keep track of failed authentication or cache the submitted salt in memory for a short period of time upon failure to decrypt, to defeat such attempts to recover secret keys.
[0167] The metadata authenticated with an AEAD pipeline provides information about encryption operations of the AEAD pipeline. For interoperability, it may include a timestamp in milliseconds, an array of encryption key identifiers (kids), and an array of nonces in base64 encoded bytes (nonces). Metadata should be encoded as a JSON object, for example {"timestamp": 1645061403369, "kids": ["keya", "keyb"], "nonces":
["base64encodednonce1", "base64encodednonce2"]}.
[0168] An embodiment should support the encryption algorithms officially approved by the jurisdictions in the FORMR Network, for example AES, Camellia, CAST5, SEED, SM4, ARIA, Salsa20, Twofish, Serpent, Magma, and Kuznyechik etc. Preferably an AEAD pipeline may comprise encryption constructions only. If an AEAD construction of a required encryption algorithm is not available, a fallback confidentiality-only construction should be created similar to the AES256-CTR-IV128 described below. When an algorithm allows multiple key sizes, a construction should use the biggest key size to provide the strongest possible protection against brute-force attacks. A construction may use an operation mode such as Galois Counter Mode (GCM), counter with cipher block chaining message authentication code mode (CCM), offset codebook mode (OCB), synthetic initialisation vector mode (SIV), AES-GCM-SIV, cipher block chaining mode (CBC), cipher feedback mode (CFB), output feedback mode (OFB), and counter mode (CTR).
[0169] In an embodiment, at least one AEAD construction is supported. XChaCha20 Poly1305 and ChaCha20-Polyl3O5-IETF are the recommended encryption constructions. These constructions do not require hardware acceleration, and implementations of these constructions are less prone to cache-timing attacks. Both are implemented in a widely ported library Libsodium, and are already included in the programming language PHP since version 7.2. Ideally an embodiment should also support a version of AES256-GCM. When choosing an architecture, the support to these encryption constructions should be a key factor to consider. The recommended architecture is a hardened linux operating system and hardware-accelerated processors with Intel SSSE3 extensions, for example Intel Westmere processors introduced in 2010 and newer models. Libsodium has an implementation of AES256-GCM available for these processors. The encryption/decryption operations can be performed in the backend application, or within a reverse proxy server. This allows more flexibility and fewer changes when deploying present disclosure on premise on legacy hardwares.
[0170] Here are the encryption constructions in order of preference. For interoperability in a network, the names below may be used during key exchange to indicate encryption constructions it can support. A FORMR Network should set the names for newly added constructions required by the participating jurisdictions. The AEAD names may be sent in upper cases. • XCHACHA20-POLY1305. A draft RFC has been submitted to IETF but it has not been standardised yet. This construction uses a 256-bit key and a 192-bit nonce. It uses the stream cipher ChaCha20 with a longer nonce, and can safely use random bytes as nonce. It is implemented in the library Libsodium available on different operating systems including IOS and Android, and programming languages. The Libsodium implementation of this construction can encrypt a message of any size (up to 264 bytes), up to 264 messages with no practical total size limit. In an embodiment, the same key and random bytes can be used as nonce for a longer period of time. For security reasons, it is still recommended to rotate keys on regular basis, or derive new secret keys for each request. CHACHA20-POLY1305-IETF. The algorithm and details are described in IETF RFC 8439, which reads "The algorithms presented here were designed to be easy to implement in constant time to avoid timing vulnerabilities". It uses a 256-bit key, 96-bit nonce. It is implemented in Libsodium. There are separate implementations in some programming languages. The Libsodium implementation can encrypt a message up to 256 GB, up to 264 messages with no practical total size limit. Keys may be rotated regularly or new secret keys can be derived for each request to avoid nonce collision if a pipeline ends with this construction. The key rotation frequency (eg daily) should be set depending on the frequency of data exchange. • AES256-GCM-LIBSODIUM. The Libsodium implementation of this construction requires hardware support, and has no software fallback. It may be used when both the client computer and the server computer support hardware acceleration for AES, and wish to avoid a fallback to a software-only implementation of AES GCM. According to Libsodium documentation, it uses a 256-bit key, 96-bit nonce, and can encrypt a message up to 64GB, up to222 (4.194 million) encryptions for messages of 1GB in length with the same key, or up to 232 (4.294 billion) encryptions for messages of 1MB in length. Both computers should derive new secret keys for each request, or rotate keys regularly (eg hourly) depending on the frequency of data exchange, and the message size. • AES256-GCM-SIV. This construction is similar to AES256-GCM-NIST96 below but may provide some protection over nonce misuse. • AES256-GCM-NIST96. This may refer to a construction following NIST standard Special Publication 800-38D, with a 256-bit key, and 96-bit nonce. The NIST standard recommends 96-bit nonces, though different key sizes and nonce sizes are allowed. Some implementations may support 96 bit nonces only. This name should be used when exchanging data with a client application, for example, with browsers which has implemented AES-GCM algorithms available in Web Crypto API. For interoperability with AES256-GCM-LIBSODIUM and with other encryption constructions, the nonce size may be fixed at 96 bits. Some implementations of this construction may fallback to software-only implementation and may be vulnerable to timing attacks. In an embodiment, this construction may be used in an AEAD pipeline, but should derive new secret keys for each request. • AES256-OCB. For interoperability, this construction should use a nonce size of 96 bits, and a tag size of 128 bits. Software-only implementations of this construction may be vulnerable to timing attacks. • AES256-CCM. For interoperability, this construction should use a nonce size of 96 bits, and a tag size of 128 bits. Software-only implementations may be vulnerable to timing attacks.
[0171] The name AES256-CTR-IV128 may refer to a fallback confidentiality-only operation if AES256 encryption is required and the above AES constructions are not available. CTR (counter) mode does not require padding. This fallback construction uses 128-bit nonces (the same as the block size of AES), and encrypts/decrypts data only. It ignores metadata, and skips authentication of ciphertext. It may append 16 random bytes to the ciphertext after encryption to conceal the construction being used in an AEAD pipeline, and remove the random bytes before decryption. This construction is vulnerable to various timing attacks, and the server may reveal the secret key under attack. An computer may use this fallback in an AEAD pipeline for compliance, but should end the pipeline with another construction (eg XCHACHA20-POLY1305 or CHACHA20 POLY1305-IETF) that can authenticate ciphertext. When evaluating proposed pipelines from another computer, a computer should skip a pipeline ending with this construction. Failure to do so will result in vulnerabilities in both computers.
[0172] A secret key shared between the client computer and the server computer should be associated with one construction only, so that either computer can know which construction to use to encrypt or decrypt with the same key. Before key exchange, one computer should present the AEAD pipelines it can support in order of preference. For example, one computer may send the following pipeline templates as a JSON array of objects: [{"id": 1, "aead":["AES256-GCM-LIBSODIUM"]}, {"id": 2, "aead": ["AES256-GCM NIST96", "XCHACHA20-POLY1305"]}, {"id": 3, "aead": ["AES256-GCM NIST96","CHACHA20-POLY1305-IETF"]}, {"id": 4, "aead": ["AES256-CTR-IV128", "XCHACHA20-POLY1305"]}, {"id": 5, "aead": ["AES256-CTR-IV128", "CHACHA20 POLY1305-IETF"]}]. The other computer can respond with the selected AEAD pipeline template depending on its capabilities to start the key exchange process. Each pipeline template may contain the unique names of constructions, which will give enough information for each computer to generate appropriate length of secret keys to associate with each operation.
[0173] When encrypting a message, a computer should perform the operations as per the sequence recorded with the key. When decrypting a message, the operations will be in reverse order. For example, if a pipeline ends with XCHACHA20-POLY1305, to decrypt a message, the recipient will start with XCHACHA20-POLY1305.
[0174] In an embodiment, the pipeline templates is editable. When new encryption constructions are added or some constructions become obsolete, users can enable or disable some templates, and create new templates of new combinations.
[0175] AES256-GCM-LIBSODIUM and AES256-GCM-NIST96 use the same operation mode (GCM) and parameters, and can decrypt the message encrypted with the other construction. The difference is the availability of a fallback to software-only implementation.
[0176] For interoperability, the ciphertext and nonces may be encoded separately in base64 format when exchanging data with other computers. The metadata may include nonces and may be sent as a HTTP header. The header name can be set by the FORMR Network and may default to X-Formr-Aead.
[0177] It is important to note that ECB mode is considered insecure, and should not be used. Incoming ciphertext encrypted in ECB mode may be rejected.
[0178] A secret key for each AEAD construction may be derived from different input key materials using key exchange algorithms and HKDF with Network Secret Salt Key as salt described later in the specification. In case one secret key is compromised, another 256 bit construction in the pipeline with a secure key may still protect data. It is recommended to use a quantum-resistant KEM in hybrid mode during the transition to quantum-resistant algorithms.
Methods to negotiate asymmetric algorithms for interoperability in key exchange and hashing
[0179] Secret keys may be derived and rotated as described in this specification, and the leading bytes of the Network Secret Salt Key may be used as the salt to a HKDF function.
[0180] A Network Secret Salt Key may significantly improve the security of derived secret keys. With key encapsulation mechanisms (KEM), client computer and the server computer may each create a pair of private and public keys, exchange the public keys and keep the private keys. Either computer can derive the same key materials using its private keys, and the other computer's public keys. Both computers can derive the same secret key of a required length by using a deterministic HKDF taking the derived key material and the Network Secret Salt Key (in full or in part) as salt, and a HMAC algorithm agreed upon. Internally, the HKDF function uses null bytes as the key of the HMAC function if no salt is used. Even if the key materials are compromised, a Network Secret Salt Key and a cryptographically strong HMAC algorithm will still keep secret keys secure.
[0181] As of February 2022, prevailing officially approved key exchange algorithms are not quantum-resistant. If an adversary records all traffic of two computers, the adversary will be able to efficiently discover the key materials derived from the current asymmetric algorithms with a powerful quantum computer in the future. The adversary may attempt to brute-force the salt to the hashing operation using Grover's algorithm (quantum search algorithm) on a quantum computer. A Network Secret Salt Key with a strong HMAC function will defeat such brute-force efforts, and keep the computer secure. It is vitally important that the adversary can not recover the Network Secret Salt Key even with recorded traffic and a powerful quantum computer.
[0182] A Network Secret Salt Key should be encrypted and saved in a database for future use. A Network Secret Salt Key should never be transmitted or viewed in plaintext using protocols that are not quantum-resistant, including web form, SSH and VPN.
[0183] Similar to encryption algorithms, there are a range of officially approved asymmetric algorithms for key exchange. The client computer and the sever computer may need to use two key exchange algorithms to meet compliance requirements. A computer can propose KEM collection templates with combinations of algorithms it supports, for the other computer to choose, then generate key pairs and exchange public keys. If more than one algorithms are used, each computer can concatenate the derived secrets in the sequence of the algorithms, and run through a standard HKDF function as described in IETF RFC 5869, taking the concatenated secrets as initial key material, and the Network Secret Salt Key (in full or in part) as salt, to derive a shared secret key.
[0184] Each computer should support key exchange algorithms officially approved by the jurisdictions in the FORMR Network, and allow system administrators to configure which algorithms or combinations of algorithms to accept. Each algorithm should use a consistent name with deterministic set of parameters such as a curve name and key size.
Here are a few examples of key exchange algorithms based on ECDH (Elliptic-Curve Diffie-Hellman) curves to explain the process to derive a shared secret key. ECDH has been standardised in NIST publication 800-56Ar2. • ECDH-P-384, which uses named elliptic curve NIST P-384 as defined in NIST FIPS 186-4 standards, * ECDH-P-521, which uses named elliptic curve NIST P-521, * ECDH-P-256, which uses named elliptic curve NIST P-256, * X25519, which is based on Curve25519 as defined in IETF RFC 7748 and included in TLS 1.3, * X448, which is based on Curve448 as defined in IETF RFC 7748, and included in TLS 1.3.
[0185] In an embodiment quantum-resistant KEM algorithms may be supported, and configurable options are available for system administrators to choose. Quantum resistant algorithms are being standardised. During the transitional period, a computer should at least support the following key exchange algorithms designed to be quantum resistant: KYBER1024, FIRESABER-KEM, NTRU-HPS-4096-821, NTRU-HPS-4096 1229, NTRU-HRSS-1373. All of these algorithms are available in liboqs from the Open Quantum Safe Project which is under active development and testing now, with bindings in a few programming languages.
[0186] To negotiate algorithms for key exchange, a computer may send a list of KEM algorithms as JSON array in order of preference under the default attribute name "kem", and a list of hashing algorithms that it can use. For example, a request body may look like this with the proposed algorithms: {"kem": [["KYBER1024", "ECDH-P-384"],"ECDH P-384", "ECDH-P-521", "X448"], "hashing": ["SHA-384", "SHA-512"], "csr": "...","aead":
[...]}. The preferred hybrid mode of KEM algorithms are included as an array. The recipient computer can look for a common algorithm from the list of algorithms that it supports, and pick the first hashing algorithm it accepts. Assuming the recipient computer accepts SHA 384 for hashing, but only supports X25519 and quantum-resistant algorithms, there is no common algorithm. The recipient computer can pick the first one from both lists, and respond with a collection of KEM algorithms under the attribute "kem", for example {"kem": ["KYBER1024", "ECDH-P-384", "X25519"], "hashing": "SHA-384", "cert":"..."}. The requesting computer can then generate key pairs accordingly, and exchange public keys encoded in PEM format. Since three algorithms are used, each computer can derive a shared key material from each key pair, and concatenate the shared key material. Each computer can derive a shared secret key of the required length (32 bytes, 256 bits), by using the leading 48 bytes of the Network Secret Salt Key as salt, and SHA-384 as hashing algorithm. In the programming language Python, a pseudo code to derive a shared secret key may look like: secret key = HKDF (algorithm=hashes.SHA384(), length=32, salt=secret-salt[:48], info=None).derive(concatenated_key_material).
[0187] In the above example, neither ECDH-P-384 nor X25519 is quantum-resistant. Since SHA-384 outputs 48 bytes (384 bits) digest, the leading 48 bytes (384 bits) of the Network Secret Salt Key works as the key to the chosen SHA-384 hashing algorithm to derive a secret key without revealing the concatenated key material. The hash function key should have the same length as the output bits. If the hashing algorithm SHA-512 is chosen which outputs 512-bit digest, then the leading 64 bytes (512 bits) of the Network Secret Salt Key will be used as the hash function key. Likewise, if SHA-256 is used, then the leading 32 bytes (256 bits) of the Network Secret Salt Key will be used.
[0188] Only one hashing algorithm is used in a HMAC algorithm. Thus for interoperability, each computer in a network should accept at least one keyed hashing algorithm defined in a NIST standard as fallback. It is recommended to enable SHA-384 as a fallback, as it outputs a digest of 384 bits, and is resistant to length extension attacks. Quantum resistant KEM algorithms and a Network Secret Salt Key play a more important role for the purpose of exchanging keys and deriving secret keys. In case two computers cannot agree on a single hashing algorithm, then one hashing algorithm may be used to derive secret keys for storage, and another hashing algorithm may be used to derive new secret keys for each request using a request salt.
[0189] Derived secret keys using HKDF may still be vulnerable if there is a vulnerability in the implementation of the hashing algorithm. To further improve security, it is recommended to use an officially approved KEM algorithm (eg ECDH-P-384) in hybrid mode, along with a quantum-resistant KEM algorithm (eg KYBER1024) in the transition to post-quantum key exchange algorithms. The public keys for key exchange should be encrypted with an AEAD pipeline and encryption keys derived from the Network Secret Salt Key.
[0190] For each key exchange, both computers can generate new private/public key pairs using the negotiated KEM algorithms. If one key pair is compromised, it will not impact other key pairs, or other computers in the FORMR Network. It is not recommended to reuse the key pairs, as doing so may lead to vulnerabilities.
[0191] RSA (Rivest-Shamir-Adleman) algorithm can optionally be used to exchange key materials, for example by encrypting key materials with the public key of the other computer. In this case, the encrypted key materials needs to be sent along with a RSA public key. This adds complexity with no benefits, and thus is not recommended.
Methods to keep secret keys and certificates secure in use and at rest
[0192] In an embodiment, derived secret keys and certificates need to be stored in a database and be available to any of the multiple web server and task handler instances running in a cluster. Secret keys and certificates should be encrypted before storing in a database to prevent unintended and unauthorised access by contractors working on premises or working in a data centre. The database should be encrypted before persisting on a hard disk.
[0193] To achieve the maximum security, all encryption keys and database passwords should be stored in an API server provided by the cluster (for example Kubernetes API server), and made available to containers as environmental variables at runtime only. If the secrets or certificates have to be provided as files to use with low level software libraries, the files should be written to a virtual directory within the container. The data stored in an API server (for example ETCD database used by the API server) should be encrypted before persisting to a hard disk. Only encrypted data is persisted on hard disks attached to worker nodes.
[0194] The cluster API servers need to keep the encryption key of the ETCD database to restore data after a crash. The cluster API servers may also keep certificates and tokens to authenticate requests from cluster users. Thus the hard disks attached to API servers may contain credentials that can not be encrypted. For this reason, when an embodiment is deployed in a data centre, it is strongly recommended to deploy cluster API servers on dedicated server nodes.
Quantum-resistant methods of exchanging data between a server computer and client computers
[0195] Some embodiments may serve data encrypted with an AEAD pipeline, and can not be accessed with a browser in the usual way. Client computers need to be particularly programmed to exchange encrypted data with the server computer and configure an embodiment in a quantum-resistant way. Applications running on client computers are a critical part of the embodiment, and may be distributed from the web service of the embodiment, or through a third party platform.
[0196] It is important to note that a standalone purposely built application on client computers may be used for important transactions. Browsers may download a web page and malicious JavaScript code linked by the web page. During internet hijacking, an impersonated server may cause a browser on the victim client computers to download and execute malicious JavaScript code. The impersonated server may use JavaScript to steal secret keys from the client computers.
[0197] In some embodiments, browsers on client computers may still be required for users to register and manage accounts in a web service. This section takes a JavaScript client application working in a browser of a client computer as an example to explain the process to derive a secret key, and to exchange encrypted data between the server computer and a client computer in a quantum-resistant way, using a hybrid mode with algorithms KYBER1024, ECDH-P-384, and SHA-384 with HKDF. Once quantum resistant algorithms are standardised and approved, the hybrid mode will be optional. In this example, the client computer uses crystals-kyber, a quantum-resistant JavaScript library, together with the Web Crypto API supported by major modern browsers. The server computer uses the programming language Python 3, liboqs-python (a Python binding to liboqs), and cryptography (a Python binding to the cross-platform library OpenSSL). The methods explained in this example apply to the interaction between server computers and client computers running other applications.
[0198] Embodiments should protect privileged API endpoints with CCA. However an adversary may still use a stolen client certificate and authentication cookies to impersonate a privileged user. Authenticating with multiple encryption may protect data and detect man-in-the-middle attacks. To achieve this, when a browser downloads a web page, the web page should not contain confidential data. It should contain templates and placeholders only, with links for the browser to download and execute the client application to fetch data from the server computer.
[0199] In the login process, when a user fills in and submits credentials, the client application may prevent the browser's default behaviour, generate a new pair of KYBER1024 public/private keys using the function K1024_KeyGen from crystals-kyber, and generate another ECDH-P-384 key pair using window.crypto.subtle.generateKey function with a EcKeyGenParams object defined in the Web Crypto API. The pseudo code to generate a KYBER1024 key pair may look like this: let pk-sk = K1024_KeyGeno; let clientk1024_sk = pksk[1].
[0200] The client application may encode and store the private keys in a permanent storage such as localStorage, and submit a message comprising algorithms and public keys as base64 encoded strings along with the credentials to the server. The submitted message in JSON format may look like this: {"user": "dmo", "password": "sTrngpA$$", "public-key": ["base64KyberPubKey","base64ECDHPubKey"], "kem":
["KYBER1024","ECDH-P-384"], "hashing": "SHA-384"}.
[0201] The server computer may validate the user credentials submitted by the client computer. If the credentials are correct, it may create a user session, and generate two new key pairs. For the algorithm KYBER1024, the server computer may create a KEM instance: k1024_instance = oqs.KeyEncapsulation("Kyberl024"), generate a key pair: k1024_public-key = k1024_instance.generatekeypairo, encode the received KYBER1024 public key as bytes: k1024_clientpublic-key, then get ciphertext and key material: k1024_ciphertext, k1024_keymaterial = k1024_instance.encapsecret (k1024_client-public-key), and finally release the resource: k1024_instance.freeo.
[0202] For the algorithm ECDH-P-384, the server computer may generate a private key: ecsk-p_384 = ec.generateprivatekey(ec.SECP384R1()), encode the received ECDH P-384 public key as bytes: ecclient pk_p_384, then get the shared key material: ecdh-key_material = ecsk-p_384.exchange(ec.ECDHo, ecclientpk_p_384).
[0203] Then the server computer may derive a secret key of 32 bytes usersession_key = HKDF(algorithm=hashes.SHA384(), length=32, salt=None, info=None).derive (k1024_keymaterial + ecdhkeymaterial).
[0204] The server computer can save the derived secret key as user session data to secure communication from now on.
[0205] In order for the client computer to have the same secret key, the server computer may export its public ECDH key: ecdhpublic-key = ecsk-p_384.public-keyo, encode bytes as base64 strings, and reply with the following response message in the response body. {"public-key": [base64_k1024_public-key, base64_ecdh-public-key], "ciphertext":[base64_k1024_ciphertext, ""], "kem": ["KYBER1024","ECDH-P-384"], "hashing": "SHA-384", "aead": ["AES256-GCM-LIBSODIUM"], "redirect": dashboardurl}. The attribute aead may instruct the client computer to encrypt messages with AES256-
GCM construction in subsequent communications. In addition, the server computer may also include authentication cookies in Set-Cookie headers, which the browser on the client computer will save automatically for future communications.
[0206] When the client application receives the response message, it can decode the received public keys and KYBER1024 ciphertext, and get the key materials from both algorithms. The pseudo decapsulation code of KYBER1024 algorithm may look like this: let k1024_keymaterial = K1024_Decrypt(ciphertext, client_k1024_sk). The key material of ECDH-P-384 algorithm can be obtained using window.crypto.subtle.deriveKey function and an EcdhKeyDeriveParams object with the server computer's public key. A personal session secret of 32 bytes can be obtained using window.crypto.subtle.deriveKey and a HkdfParams object with the concatenated key materials, and "SHA-384" as the hashing algorithm. The client application should save the personal session secret (PSS) key and the AEAD pipeline in a permanent storage before rendering the dashboard user interface, or causing the browser to load the dashboard URL.
[0207] On the dashboard page, the client application may request data from the server computer. For requests using the HTTP verb GET, the client application can create a metadata object to include timestamp, the URL with query parameters, a random nonce, and a key identifier. The client application may generate a random request salt of 48 bytes to use with SHA-384. The metadata may look like this: {"nonces": ["b64CientNoncel"], "timestamp": 1645061500302, "url": "...", "kids": ["pss"], "salt": "b64ReqlSalt"}. The client application can derive a new secret key for the request, using window.crypto.subtle.deriveKey and a HkdfParams object including the generated salt, the personal session secret key, and "SHA-384" as the hashing algorithm. The client application can encrypt a random string with the AEAD pipeline and the new secret key for this request to get a ciphertext. The client application can include the ciphertext in a custom header X-Formr-Token, and include the metadata in a custom header X-Formr Aead. A JavaScript library such as jQuery may process the custom headers to include in request headers before sending a request to the server computer over a TLS-encrypted connection.
[0208] Upon receipt of the request, the server computer can authenticate the request by checking the timestamp, deriving a new secret key for the request using the salt received and personal session secret key, decrypting the token, and comparing the URL and query parameters. Important parameters should be taken from the metadata to prevent tampering and man-in-the-middle attacks.
[0209] After retrieving and processing requested data, the server computer can create a nonce, encrypt a response message with the AEAD pipeline and the new secret key for the request, and reply with a base64 encoded ciphertext in the response body. The server computer should also set the associated response metadata in a custom header X-Formr Aead, which may look like this: {"timestamp": 1645061503369, "kids": ["pss"], "nonces":
["b64ServerNoncel"], "requestnonces": ["b64ClientNoncel"], "salt": "b64Req1Salt"}. The client application can decode the data with the received nonce and the secret key for the request, and render the data in the user interface, for example a web form. For interoperability, the metadata should be encoded as JSON.
[0210] When a user submits the web form, the client application can prevent the browser's default behaviour, create a nonce, generate a new salt to derive a secret key for the request, encrypt a request message comprising the web form data to get a ciphertext, and send the base64-encoded ciphertext as request body to the server. The client application should also set the metadata in a custom header X-Formr-Aead, which may look like this: {"timestamp": 1645062503369, "kids": ["pss"], "nonces":
["b64ClientNonce2"], "url":"...", "salt": "b64Req2Salt"}. For interoperability, the metadata should be encoded as JSON. The server computer can derive a new secret key from the salt and personal session secret key, authenticate and decrypt the ciphertext to get a request message, process the request message, and reply with an encrypted response message over the TLS-encrypted connection.
[0211] During incidents of internet hijacking, the encrypted data and authentication cookies could be sent to a fake server. If an endpoint is not protected with mTLS, or an adversary has a stolen client certificate, the adversary may use the stolen credentials to download more encrypted data from the server computer, and submit forged data to the server computer. An adversary does not have the personal session secret and will not have access to the data. The server computer should keep a record of client certificates and users of failed decryptions, terminate the user session and suspend the client certificate if failed decryptions have exceeded a configurable allowed threshold. If the client computer fails to authenticate or decrypt the encrypted response message, it can display a warning to alert the users.
[0212] In an embodiment, the server computer may create new key pairs to derive secret keys for each user session. This way, a stolen private session secret will not comprise other user sessions.
[0213] To prevent man-in-the-middle attack and manipulation of requests and responses, a client computer can include the URL and query parameters in the metadata before AEAD operation. It is important to note that query parameters in a URL are automatically decrypted. Confidential parameters should be submitted as ciphertext in the request body. In some embodiments, the client computer may generate a unique request identifier and include it in a request header. In some embodiments, the client computer may use request nonces as a request identifier. The server computer can include the request identifier in the authenticated response metadata. The client application can check the echoed request identifier against the sent request identifier to detect tampering. This way, both the server computer and the client computer can detect tampering of request/response.
Random Padding of Messages
[0214] Encrypting the same message with an AEAD pipeline will produce a ciphertext of the same length. An adversary may guess the message using statistical analysis of message lengths. To defend against such attacks and chosen-plaintext attacks, before encryption, server computers and client computers may prepend a message with X random bytes, append the message with Y random bytes, and concatenate with a first indicator of one or more bytes representing the number X and a second indicator of one or more bytes representing the number Y. Both indicators can have the same length. Each indicator of L bytes can represent a number between 1 and 8 2 x L. Two indicators of L bytes can create 216x L permutationsofprependedandappendedbytes.Ifamessage
has been padded, the server computers and client computers may include an extra key paddingindicatorlength with a value set to an array of the lengths of indicators in associated request metadata or associated response metadata, for example [1, 1]. This can make the lengths of ciphertexts unpredictable, and make it harder to launch chosen plaintext attacks.
Methods to negotiate asymmetric algorithm for digital signing and client certificate
[0215] Embodiments should protect privileged API endpoints with client certificates, to mitigate the risk of timing attacks against encryption keys on the server. Using a public
CA may create complexity, limitations, administration burdens and vulnerabilities. For best security, each embodiment should operate as a private Certificate Authority (CA), and decide what digital signing algorithms it will use for the private CA keys. For compatibility with other embodiments, an embodiment should use multiple CA certificates to support common signing algorithms. When mutual TLS is enabled, in a timing attack, an adversary needs a client certificate to create a TLS-encrypted connection to the server and measure the response time to fabricated ciphertext. Client certificates with non quantum-resistant signing algorithms may still provide strong protection now, though quantum-resistant signing algorithms should be used once available.
[0216] Though it is possible to issue a hybrid client certificate where a certificate holder and CA use keys of different algorithm, doing so may cause compatibility issues. It is recommended for an embodiment to request for a certificate with one of the algorithms that the private CA uses.
[0217] Each embodiment should implement TLS endpoints to reply with a list of signing algorithms it supports in order of preference, and to issue certificates after receiving certificate signing requests (CSRs) from other embodiments so that other embodiments may access its mTLS endpoints.
[0218] Each embodiment should support RSA for compatibility, and the ECDSA (Elliptic Curve Digital Signature Algorithm) algorithms officially approved by the jurisdictions in the FORMR Network, using standard names for interoperability when negotiating signing algorithms, for example: • ECDSA-P-384, using named elliptic curve NIST P-384, • ECDSA-P-521, using named elliptic curve NIST P-521, • ECDSA-P-256, using named elliptic curve NIST P-256. • RSA, with a 4096-bit or longer keys. It is estimated 15360-bit RSA keys are equivalent to 256-bit symmetric keys in security level. It is recommended to use another algorithm to sign client certificates with RSA keys as a fallback.
[0219] Each embodiment should support the following EdDSA algorithms which are available in OpenSSL 1.1.1: • ED25519, as defined in IETF RFC 8032 and NIST FIPS 186-5, and included in TLS 1.3. It uses SHA-512 and elliptic curve Curve25519 and the implementations may be resistant to timing attacks. This is the recommended algorithm for client certificates issued to other embodiments, before quantum-resistant algorithms are available in software libraries. • ED448, as defined in IETF RFC 8032 and NIST FIPS 186-5, and included in TLS 1.3. It uses SHA-3 and elliptic curve Curve448.
[0220] Each embodiment should support quantum-resistant signing algorithms. As the algorithms are being standardised, during the transitional period, each embodiment should support a standardised algorithm as soon as the algorithm is implemented in software libraries. A standard signing algorithm is likely to be one of DILITHIUM5, DILITHIUM5-AES, and FALCON-1024 available in liboqs.
[0221] Each embodiment should allow system administrators to define a list of signing algorithms enabled for signing client certificate in order of preference.
[0222] It is important to note that due to the limitation of mutual authentication process, client certificates may have to be saved on a hard disk for use by low level libraries when authenticating with a server. Thus client certificates could be stolen. It is not recommended to use client certificates as the only authentication factor for API endpoints.
Methods to roll out client certificate on user devices
[0223] Each embodiment should provide downloadable client certificate and private key bundle in PKCS12 format as defined in IETF RFC 7292 as a CCA rollout option on user devices. These downloadable bundles may make it easy to implement and enforce mutual authentication for users of high privileges, for example officers and employers who can access information of multiple registered workers. It is highly recommended but not always feasible for individuals to obtain a client certificate by generating a key pair, submitting a CSR, waiting for it to be manually approved, and then creating a PKCS12 bundle to import into a browser.
[0224] The downloadable bundles can be created with key serialisation tools provided in a binding to a SSL/TLS library such as OpenSSL. It is important to note that PKCS12 encryption may be required to import the certificate bundle into some browsers such as Firefox. PKCS12 encryption is very weak and should not be relied upon to transmit the certificate bundle over insecure channels such as emails. A compromised client certificate may make the system vulnerable to exploitations such as timing attacks.
API structure and Remote Procedure Call
[0225] For interoperability, each embodiment should provide an API following the sharing protocol agreed by the regulators, or a default RESTful API. Each network is for a particular industry and may agree on one API structure for backward compatibility.
[0226] In some cases an embodiment may need to exchange information with other embodiments within the same jurisdiction, but across industries. To enable one embodiment to request for client certificate and share secrets with other embodiments, each embodiment may implement a Remote Procedure Call (RPC). A RPC can map a dotted path to a whitelisted internal method, and may make it possible for an embodiment to join multiple FORMR networks without changing API structure. For interoperability, each embodiment should implement an API endpoint (default to the root path "/") to accept RPC requests submitted as a query parameter or in the request body under the attribute "cmd". When an AEAD construction is used to authenticate a RPC call, the RPC should be included in the AEAD metadata under the attribute "cmd" in a custom HTTP header X-Formr-Aead.
Cluster Components of a typical embodiment
[0227] In at least one of the embodiments, the present invention may be implemented as a multitude of containerised computer processes running in a Kubernetes cluster of physical servers or virtual private servers (VPS). It can be deployed on premise or in a data centre chosen by the regulator deploying the system. Kubernetes is the recommended technology to build the underlying cluster to run an embodiment, though it is also possible to build a cluster with other technologies supporting Open Container Initiative (OCI) specifications, such as Docker Swarm or Cloud Foundry. Kubernetes is preferred as it allows low level control of container images and container runtime including role based access control (RBAC) and security context, which are important to limit runtime privileges and manage cyber security risks. There are more tools and technicians available to manage Kubernetes clusters. In addition, Kubernetes API servers can serve as a secret vault, making secrets available to containers at runtime.
[0228] An embodiment may comprise the following cluster components working together to monitor internet services, mitigate cyber security threats, provide a high availability web service, and protect the API it consumes. It should be noted for high availability, each component may have multiple replicas running on one server or multiple servers.
• Domain Name System (DNS) monitor. This component can monitor the DNS resolution of the domain names assigned to the web services of the embodiment, and the regulator's registration/compliance/backup systems. It can push the monitoring results to a centralised in-memory storage component to control the work flow of other components such as Queue Publisher and Queue Handler. This component can monitor DNS resolution from a configurable list of DNS servers, which at least include the default DNS servers of local Internet Service Providers (ISP), and some well known DNS servers that users might be using, such as the DNS servers provided by Google or Cloudflare. • Border Gateway Protocol (BGP) monitor. This component may monitor BGP announcements related to the configurable Internet Protocol (IP) addresses of concern, and push the monitoring results to the centralised in-memory storage. The monitoring results may decide the workflow of other components, such as Queue Publisher and Queue Handler. • Centralised in-memory storage and queue. This component may store tasks in queues, and the DNS/BGP monitoring results. It may be the brain of an embodiment. • Queue Publisher. This component may push tasks to the queue at interval, for example the tasks to pull data from the regulator's registration/compliance system, and the tasks to push symmetrically encrypted data to embodiments of other regulators. • Queue Handler. This component may fetch tasks from queues, and check DNS/BGP monitoring results before processing tasks. It may return tasks back to the queue if network monitoring results are abnormal. • Configurable Inbound Data Mapper. This component may map received data to the embodiment's customised document schema. • Configurable Outbound Data Mapper. This component may map the embodiment's customised document schema to the agreed information sharing data structure when pushing data to other embodiments. • Configurable Notification Handler. This component may listen to document events and notify recipients when document events meet predefined conditions.
• Ingress Controller with Client Certificate Authentication (CCA) support. This component may map incoming web requests to the web server component, facilitate secure Transport Layer Security (TLS) connection with the web client, and validate client certificates before granting access for domain names with CCA enabled. • X.509 Client Certificate Issuer. This component may sign client certificates with configurable Certificate Authority (CA), and issue certificates and private keys as a downloadable bundle to users with high privileges in the embodiment. • Web Application Firewall (WAF). This component may filter and limit incoming web requests, stop brute-force attacks against login credentials and authentication cookies, and reduce web servers' consumption of resources. It can check the DNS/BGP monitoring results, and when the monitoring results are abnormal and a client certificate is not present, invalidate user sessions per system settings. • Web Server. This is the actual business logic for API endpoints and graphic user interface for stakeholders. It can handle web requests from human users and machines, exchange symmetrically encrypted data with client applications and other embodiments, and provide a portal for registered workers to manage private information. • Database storage. This component can persist data on hard disks and make database available when a part of the infrastructure fails. The database storage should support encrypting data at rest, and backing up of encrypted data. • Database proxy. This component can monitor the health of database storage nodes, and proxy connections to healthy nodes only. • Logger. This component can log access and sharing of data for auditing, analysis and security review. • Backup Pusher. This component can check DNS/BGP monitoring results, and when the results are normal, push data to regulator's backup storage system.
Methods of protecting the API endpoints consumed
[0229] If an embodiment is deployed in a data centre and pulls information from a regulator's registration/compliance systems on premise, a connector will be required to run behind the regulator's firewall and be able to accept incoming HTTPS connection. A connector can be a reverse proxy server that supports TLS 1.2 and 1.3, client certificate authentication, and configurable scripting. In at least one of the embodiments, the connector can be implemented with a reverse proxy server such as Nginx, programmable scripting within the reverse proxy server such as ngxhttpluamodule, and an AEAD operation resistant to timings attacks, such as XCHACHA20-POLY1305 or AES256 GCM-LIBSODIUM. The connector can accept HTTPS connection with client certificate, validate an encrypted token with timestamp metadata, validate the source IP address, and proxy the connection to registration/compliance systems using HTTP protocol on the local area network. The connector can have access to API credentials as environment variables in the reverse proxy server, and send the API credentials as required to the registration/compliance systems. Before sending a response, the connector can include the request nonce in the metadata, and encrypt the data from registration/compliance systems with one AEAD operation and a secret key shared with other components. The connector can demand a valid client certificate signed with a private CA key before establishing a HTTPS connection, to protect the registration/compliance systems against exploits of published and undisclosed vulnerabilities. In case the client certificate has been stolen, the reverse proxy server can still protect the backend by validating source IP address and authenticating a token with an AEAD operation.
[0230] In case a regulator uses SaaS solutions provided by a third party for registration/compliance, an embodiment should monitor BGP/DNS and pull information when it is safe to do so. This may reduce the possibilities of sending API credentials to a fake server during internet hijacking. However readers should be aware that data and credentials could be stolen when officers access the third party SaaS systems during internet hijacking. The transmissions may not be quantum-resistant either. The use of generic SaaS solutions for registration/compliance could be a cyber security risk to all regulators in the network, and such regulators should notjoin a FORMR Network handling sensitive information.
Methods of deriving shared secret keys and creating a FORMR Network
[0231] Two embodiments can create a FORMR Network by negotiating an AEAD pipeline and exchanging keys accordingly. Before creating a network, both embodiments should have set up AEAD templates and enabled algorithms properly, passed internal security audits, and enabled CCA. To create a new network, two embodiments can start by exchanging a Network Secret Salt Key using a secure established communication channel, requesting for a client certificate from each other, then exchange public keys of KEMs to derive shared secret keys. If both embodiments support a post quantum KEM, a Network Secret Salt Key can be derived by exchanging keys in hybrid mode. This section explains the process of issuing client certificates, deriving a Network Secret Salt Key, negotiating an AEAD pipeline, and exchanging keys. In addition, this section also explains how to derive a Daily Network Secret to assist in the process of obtaining client certificate and exchanging keys. For easy reference, the server computers of founding embodiments are referred to ER1 (the server computer of embodiment of Regulator 1) managed by R1CIO (the Chief Information Officer or delegate of Regulator 1) using a client application ER1App, and ER2 (the server computer of embodiment of Regulator 2), managed by R2CIO using ER2App.
[0232] To prevent exchanging keys with an impersonated server, both embodiments should generate a pair of public/private keys for signing messages, exchange the generated public keys, and store the public and private keys to verify each other's signature before a Network Secret Salt Key is available. Preferably a quantum-resistant digital signature algorithm is used to generate the signing keys. The keys to sign messages are for temporary use and may be different from the keys to sign client certificates.
[0233] In a process to edit a new regulator record in ER1, when R1CIO logs into ER1 using ER1App, ER1 may validate the client certificate and credentials, and exchange keys with ER1App in a quantum-resistant way to derive a 256-bit personal session secret (PSS). All communications may be encrypted with an AEAD pipeline and the PSS, or a secret key derived from the PSS and a request salt.
[0234] ER1App may render a web form for R1CIO to fill in the details (such as the name, TLS URL and mTLS URL) of ER2, and a button to trigger the CSR process. On clicking or tapping of the button by R1CIO, ER1App may encrypt the web form data with PSS and submit to ER1. ER1 may decrypt data with PSS, validate and save the form data, and create or updates a regulator record. Upon saving of the regulator record, ER1 may check the existence of a valid client certificate issued by ER2. Since a valid certificate does not exist, ER1 may add a background job to a queue to create a CSR, and acknowledge success so that ER1App can display an appropriate message to R1CIO. ER1 can retry a background job on failure, and avoid R1CIO waiting for a result. The process to create a new regulator record ends.
[0235] In a background CSR process in ER1, a task handler of ER1 may watch queues for new jobs, and retrieve the form data to start the job. ER1 may send a RPC request (formr.cca.getsigningalgorithms) to a public TLS endpoint of ER2. ER2 may respond with an object containing a list of certificate signing algorithms that it has enabled in CCA. The response may look like this: {"signingalgorithms": ["ECDSA-P-384", "ECDSA-P 521", "RSA"]}. ER1 may pick the first algorithm from the list (ECDSA-P-384 in this example), generate a pair of public/private keys for client certificate, and create a certificate signing request (CSR). A CSR comprises information about ER1 digitally signed with the generated private key. ER1 may check for agreed algorithms of AEAD pipeline, hashing and key exchange, and may find none. ER1 may compose a request message comprising the CSR, proposed AEAD pipelines between ER1 and ER2, KEMs, hashing algorithms between ER1 and ER2, and a random string as bearer token to a TLS endpoint of ER2. The purpose of bearer token is to prevent spam in a public API, and for manual authentication between R1CIO and R2CIO. The request message may look like this in JSON: {"cmd": "formr.cca.requestclientcertificate", "csr":"...","aead": [{"id": 1, "aead": ["AES256-GCM-LIBSODIUM"]}, {"id": 2, "aead": ["AES256-CTR-IV128", "XCHACHA20-POLY1305"]}], "kem": [["KYBER1024", "ECDH-P-384"], "ECDH-P-384"], "hashing": ["SHA-384", "SHA-512"], "installcertificatetoken": "B64RandomString", "kid": "key_id_randomstring"}. The key id (kid) may refer to the id of ER1's private key for the client certificate. The key pair and the CSR can be created with a binding to a SSL library such as OpenSSL. ER1 may save the pair of keys and the bearer token in a database for future use. It is recommended to use a separate private key for each certificate. ER1 may send the request message along with headers to ER2.
[0236] Upon receipt of a CSR and proposed algorithms, ER2 may proceed to manual approval process. It may save the received CSR and proposed algorithms, acknowledge receipt of the CSR with an empty object in the response body, and notify R2CIO for a decision. To prevent spam, each embodiment can have a configurable option to disable certificate request when all embodiments of a network have joined the network.
[0237] The task handler of ER1 may receive a success code and an empty object, finish the job and watch the queue for new jobs. The background CSR process ends.
[0238] In a new process to approve a CSR in ER2, when R2CIO logs into ER2 using ER2App after receiving a notice, ER2 may validate a client certificate and credentials and create a quantum-resistant data exchange channel similar to the channel between ER1 and ER1App. ER2App may render a form to display CSR details with a button to approve the request, and the option to create a new network by default, or add ER1 to an existing network. In this example a new network will be created as no network exists yet. R2CIO may select a KDF, a hashing algorithm to use with the KDF, and an AEAD pipeline for authenticating new embodiments in the network. For interoperability in the network, the KDF is recommended to be HKDF, the hashing algorithm is recommended to be SHA 384, and the AEAD pipeline is recommended to be ["CHACHA20-POLY1305-IETF"].
[0239] Upon R2CIO enters a new network name, selects options, and clicks the button to approve the CSR, ER2App may encrypt the web form data and submit to ER2. ER2 may decryptthe web form data, create a network with a UUID4 id and the provided name, and create a regulator record to represent ER1. ER2 may sign a client certificate, create an API key for ER1, associate the API key with the certificate, save the details of network, regulator, certificate details in a database, and save the accepted algorithms for future key rotation with ER1. ER2 may add a job to a queue to install certificate, and respond with success for ER2App to display an appropriate message to R2CIO. The process to approve CSR ends.
[0240] In a new background process in ER2 to install certificate in ER1, ER2 may post a message comprising the certificate along with accepted algorithms and network information to a public TLS endpoint of ER1. ER2 may sign the message with its private key corresponding to the public key exchanged with ER1 for signing, and set the digital signature in a custom HTTP header X-Formr-Signature. The message sent to ER1 may look like this in JSON format: {"cmd": "formr.cca.intall_clientcertificate", "certificate": "aead": [{"id": 2, "aead": ["AES256-CTR-IV128", "XCHACHA20-POLY1305"] }], "kem":
["KYBER1024", "ECDH-P-384"], "hashing": "SHA-384", "installcertificatetoken": "B64RandomString", "kid": "keyidrandom_string", "networkid": "2b8b5853-...", "networkname": "Electricians", "networkkdf': "HKDF", "networkhashing": "SHA-384", "networkaead":["CHACHA20-POLY1305-IETF"], "apikey": "er2ApiKey4Er1"}. The API key is one of the authentication factor, and should be used together with the client certificate. When consuming another embodiment's API, the API key should be included as a configurable custom HTTP header which defaults to X-Formr-Apikey.
[0241] Upon receipt of the post data, ER1 may retrieve the private key for client certificate with the key identifier, compare the bearer token, and reject the request if the received data does not match records it has. ER1 may verify the signature of the received message with ER2's public key for signing. In this example the bearer token matches and the received signature is valid. ER1 may save the network name and ID received, the API key, the certificate and the accepted algorithms in a database, and save the certificate and private key on a hard disk for use by low level libraries when connecting to mTLS endpoints of ER2. ER1 can optionally notifies R1CIO that the certificate has been installed.
[0242] Upon saving of a client certificate received, ER1 may check for the existence of the Network Secret Salt Key by this network id, and end the process if a Network Secret Salt Key exists. Since a Network Secret Salt Key does not exist in this example, ER1 may check whether the agreed KEM algorithms include at least one quantum-resistant algorithm. If no quantum-resistant KEM is available, it should remind R1CIO to exchange a Network Secret Salt Key securely or enable a quantum-resistant KEM, and end the process. In this example, both conditions are met, ER1 may add a background job to a queue to establish a Network Secret Salt Key. The process to install certificate ends.
[0243] In a background process in ER1 to establish Network Secret Salt Key, ER1 may send a request to a mTLS endpoint of ER2 to inquire about the Network Secret Salt Key, with a pseudo request message like this {"cmd": "formr.kem.getsecretsalt length", "networkid": "2b8b5853-..."}. Since a Network Secret Salt Key does not exist yet for this network, ER2 should respond with a message like this {"secretsaltlength": 0, "networkid": "2b8b5853-....
[0244] Then ER1 may generate one new KYBER1024 key pair, one new ECDH-P-384 key pair, and post a RPC request to a mTLS endpoint of ER2. The pseudo request message may look like this: {"cmd": "formr.kem.createsecret_salt", "kem":
["KYBER1024", "ECDH-P-384"], "hashing": "SHA-384", "public-key":
["ER1b64KyberPublicKey...", "ER1b64EcdhPublicKey..."], "networkid": "2b8b5853-.... For interoperability among embodiments, the ECDH public keys should use PEM encoding and SubjectPublicKeylnfo format which comprising an algorithm identifier and the public key as a bit string. The public key of quantum-resistant KEM should use base64 encoding.
[0245] Upon receipt of the request after validating the client certificate, ER2 may check for the Network Secret Salt Key in its database, and reject the request if a Network Secret Salt Key exists. In this example a Network Secret Salt Key does not exist, ER2 then may check that the KEM algorithms are the same as agreed upon, and one of the algorithms is quantum-resistant. If the conditions are not met, ER2 would reject the request. In this example all conditions are met, ER2 may proceed to create one new KYBER1024 key pair, and one new ECDH-P-384 key pair. ER2 may get the key materials using its private keys and the public keys, concatenate the key materials, and derive the Network Secret Salt Key using HKDF and the agreed HMAC algorithm. A pseudo code to derive the Network Secret Salt Key may look like this in the programming language Python: secretsalt = HKDF (algorithm=hashes.SHA384(), length=64, salt=None, info=None).derive(concatenatedkeymaterial).
[0246] At this point, ER2 encrypts with a database encryption key and saves the Network Secret Salt Key in the database for use as salt when deriving shared secret keys for this network in the future.
[0247] Upon successful saving to a database, ER2 may encode its public keys, and composes a response message like this:: {"kem": ["KYBER1024", "ECDH-P-384"], "hashing": "SHA-384", "public key": ["er2b64KyberPubKey...", "er2b64EcdhPubKey..."]}. ER2 may sign the message with its private key corresponding to the public signing key shared with ER1, set the digital signature in a custom HTTP header X-Formr-Signature, and reply with the response message in the response body.
[0248] Upon receipt of the response, ER1 may verify the digital signature using the public signing key of ER2 that ER1 keeps on record. ER1 may reject the response if the signature is invalid. In this example, the signature is valid, ER1 may derive key materials using its private keys and ER2's public keys, concatenate the key materials, and derive the same 64 bytes of the Network Secret Salt Key with HKDF and HMAC algorithm using SHA-384 for hashing operation. ER1 may encrypt with a database encryption key and save the Network Secret Salt Key with the network id in the database for future use. ER1 may check the existence of secret keys with ER2, and add a background job to a queue if the secret keys do not exist. The background process to create Network Secret Salt Key ends.
[0249] In a background process in ER1 to exchange keys for the agreed AEAD pipeline, since there are two constructions in the pipeline, ER1 may create a new pair of
KYBER1024 keys and a new pair of ECDH-P-384 keys for each construction, 4 pairs of keys in total. In addition, for each construction, ER1 may generate a random key id to identify the secret key and AEAD construction in the metadata in the future. The key id should be a UUID4 string for simplicity and interoperability. The agreed AEAD pipeline constructions are ["AES256-CTR-IV128", "XCHACHA20-POLY1305"], so ER1 may create one nonce of 16 bytes for AES CTR mode, and one nonce of 24 bytes for XChaCha20. The AEAD metadata may look like this: {"timestamp": "1645602635511", "kids": ["2b8b5853-...","2b8b5853-..."], "nonces": ["b64Nonce4Aes", "b64Nonce4XChaCha"], "utcdate": ["2022-02-23:0", "2022-02-23:1"], "cmd": "formr.kem.exchangekeys-for-aead"}. Since the keys have not been exchanged yet, both embodiments only have the Network Secret Salt Key in common, the number of encryption keys required can be derived from the Network Secret Salt Key by passing utcdate and zero-based key index as "info" parameter to the HKDF function and the agreed hashing algorithm. ER1 may generate a request salt of 48 bytes to derive a new secret key for this request, and include the request salt in the metadata. A pseudo code to derive the first key may look like this: secretkeyo = HKDF(algorithm=hashes.SHA384(), length=32, salt=request salt, info="2022-02 23:0").derive(secret-salt). The pseudo code to derive more keys: secret-key_1 = HKDF(algorithm=hashes.SHA384(), length=32, salt=request salt, info="2022-02 23:1").derive(secret-salt). In this example both constructions use a key of 32 bytes. If an AEAD construction needs a key of different length, the secret keys can be derived by setting the required key length. This API request needs symmetric encryption protection as some key exchange algorithms may not be quantum safe, and client certificates could be stolen. After dumping the metadata as a JSON string, ER1 may encrypt the request message with the AEAD pipeline, encodes the ciphertext as base64 string, and add the metadata in a custom header X-Formr-Aead. ER1 may post a request to a mTLS endpoint of ER2, with a pseudo message looking like this before encryption: {"cmd": "formr.kem.exchangekeys-foraead", "aead": ["AES256-CTR-IV128", "XCHACHA20 POLY1305"], "kem": ["KYBER1024", "ECDH-P-384"], "hashing": "SHA-384", "public-key": [{"kid": "6dal7678-...", "public key": ["ER1b64KyberPubKeyAes", "ER1b64EcdhPubKeyAes"]}, {"kid": "d1c510c4-...", "public-key":
["ER1b64KyberPubKeyChaCha","ER1b64EcdhPubKeyChaCha"]}]}.
[0250] Upon receipt of the request after validating ER1's client certificate, ER2 may check the metadata in the custom header X-Formr-Aead, and discard the request if the timestamp is suspicious. It should allow utcdate to be from the previous day if the current UTC time is shortly after midnight. Then ER2 may retrieve the Network Secret Salt Key of the network, derive the same number of secret keys using HKDF, the agreed HMAC SHA-384 and the request salt. ER2 may decrypt the request data in reverse order of the agreed AEAD pipeline. The request should be rejected if it can not be decrypted. If decryption is successful, ER2 may generate 4 pairs of keys accordingly, use its private keys and ER1's public keys to derive the key materials, concatenate key materials for each AEAD construction, and derive the secret keys using HKDF and the leading 48 bytes of the Network Secret Salt Key as salt. The pseudo code may look like this in Python: aessecret-key = HKDF (algorithm=hashes.SHA384(), length=32, salt=secret salt[:48], info=None).derive(concatenatedkeymaterialaes). xchachasecretkey = HKDF (algorithm=hashes.SHA384(), length=32, salt=secret-salt[:48], info=None).derive(concatenated_keymaterialxchacha). ER2 may save the derived secret keys with metadata (the received key id, counterpart (ER1), associated AEAD construction) in a database, and compose a response message. An API key may identify the source of data in the system, and is one of the authentication factor that can be revoked in real time under attack to deny access. The pseudo response message may look like this: {"public key": [{"kid": "6da17678-...", "public key":
["ER2b64KyberPubKeyAes", "ER2b64EcdhPubKeyAes"]}, {"kid": "d1c510c4-...", "public-key": ["ER2b64KyberPubKeyChaCha", "ER2b64EcdhPubKeyChaCha"]}]}. ER2 may generate two nonces for each construction in the agreed AEAD pipeline, prepare metadata, include request nonces in the metadata, encrypt the response message with the AEAD pipeline, and reply to ER1.
[0251] Upon receipt of the response, ER1 may validate utcdate and timestamp in the custom header, compare received request nonces in the response metadata against request nonces sent to ER2, and attempt to decrypt the response with the secret keys for this request. If the decryption is successful, it may use its private keys and ER2's public keys to derive key materials, concatenate key materials for each AEAD construction, and use HKDF with the leading 48 bytes of Network Secret Salt Key as salt to derive the secret keys. ER1 may save the secret keys with metadata (the key id, counterpart (ER2), and associated AEAD construction) in a database for future use. ER1 may check whether it has issued a client certificate for ER2. In this example ER1 has not issued a certificate to ER2 yet. ER1 may queue a background job to invite a CSR from ER2. The background process to exchange AEAD keys ends.
[0252] In a new background process in ER1 to invite CSR from ER2, ER1 may send a request to a mTLS endpoint of ER2, with pseudo data like this: {"cmd": "formr.cca.invite-csr", "network-id": "2b8b5853-..."}. ER2 may queue a background job to create an authenticated CSR, and acknowledge success to ER1. The process to invite CSR ends.
[0253] In a new background process in ER2 to create an authenticated CSR, ER2 may send a RPC request (formr.cca.getsigningalgorithms) to a TLS endpoint of ER1 to get a list of signing algorithms. ER1 may respond with data{"signingalgorithms": ["ECDSA P-521", "ECDSA-P-384", "RSA"]}. ER1 may pick the first signing algorithm from the list (ECDSA-P-521 in this case), generate a pair of public and private keys, and create a CSR. In addition, though a CSR does not need encryption, since ER1 has the Network Secret Salt Key for the network, it can use a selected network AEAD pipeline which is a CHACHA20-POLY1305-IETF construction for API authentication. Implementations of CHACHA20-POLY1305-IETF are less vulnerable to cache-timing attacks and are chosen as an authentication factor for this TLS endpoint. ER2 may generate a request salt of 48 bytes, and derive a daily network secret for this request. The pseudo key derivation code may look like this: request-secret-key = HKDF(algorithm=hashes.SHA384(), length=32, salt=request_salt, info="2022-02-23").derive(secret-salt). ER2 may create a nonce of 12 bytes, and prepare metadata like this: {"timestamp": "1645614834478", "kids":
["2b8b5853-..."], "utcdate": "2022-02-23", "nonces": ["B64Nonce4ChaCha"], "salt": "B64ReqSalt"}. ER2 checks for agreed algorithms on key exchange, hashing and AEAD pipeline, finds the algorithms it has agreed with ER1, and skips proposing algorithms in the request. The request message looks like this before encryption: {"cmd": "formr.cca.requestclientcertificatewithauth", "csr": "...", "kid": "er2_privatekeyfor_er_cert", "installcertificatetoken": "B64RandomStringbyEr2"}. ER2 may encrypts the request message with metadata, set the metadata in a custom header X-Formr-Aead, and send a RPC (formr.cca.request_clientcertificate-withauth) request to a public TLS endpoint of ER1.
[0254] Upon receipt of the CSR, ER1 may check the custom header X-Formr-Aead, validate the timestamp and utcdate, and derive the daily network secret using the request salt and Network Secret Salt Key. ER1 may attempt to decrypt the request body with the network AEAD pipeline and the daily network secret for this request. If decryption fails, ER1 rejects the request. In this example decryption succeeds, which means ER2 has authenticated to get a client certificate. ER1 signs a client certificate with its private CA key, saves the details of the certificate in a database, and adds a background job to install certificate in ER2. ER1 may encrypt a response message comprising an empty object with the network AEAD pipeline and the daily network secret for this request to get a ciphertext. ER1 may respond with success code and the ciphertext. The process to create an authenticated CSR ends.
[0255] In a new background process in ER1 to install certificate in ER2, ER1 sends the certificate along with key id and the token to install certificate. ER2 validates the token, saves the certificate in a database, and saves the private key and certificate to the hard disk for use by low level libraries when connecting to mTLS endpoints of ER1. ER2 proceeds to check the existence of secret keys for use with ER1. ER2 finds the secret keys, and skips the key exchange process. ER2 responds with success code. This is the end of the process to install certificate in ER2.
[0256] In the same way, an embodiment may establish a new network with another embodiment to securely exchange data. It can use the same background process to exchange public keys with other embodiments, derive new shared secrets and rotate secret keys for AEAD pipelines regularly.
[0257] If any process takes place during incidents of internet hijacking, it is possible for CSRs, client certificates and public keys to be sent to a fake server. None of these stolen data will become a security threat to the FORMR Network currently or in the future. CSRs are useless before signing. Client certificates need to work together with a private key, which always stays on the server. Quantum-resistant algorithms are used in hybrid mode to create or securely share Network Secret Salt Key. Public keys of ECDH algorithms are vulnerable to quantum attack, and are symmetrically encrypted before exchanging with another embodiment. As long as the Network Secret Salt Key is kept secret, the encrypted data in transit in a FORMR Network will be secure.
[0258] Some embodiments in a network may disable automated issuing of client certificates to other embodiments, and require manual verification of identities. Some embodiments may enable automated issuing of client certificates to other embodiments only after an applying embodiment has been accepted by a minimum number of embodiments in the network.
Methods to join an existing FORMR Network and exchange secret keys
[0259] The process for an embodiment to join an existing network is similar to how ER1 submits a CSR to ER2 and waits for a manual approval in the above example. Since a Network Secret Salt Key already exists, the new embodiment will receive an encrypted Network Secret Salt Key instead of creating a new one. In this example to explain the process, ER3 (the server computer of the embodiment of Regulator 3) is managed by R3CIO (Chief Information Officer or delegate) with ER3App. ER3 gets a certificate from ER2 with manual approval to receive the Network Secret Salt Key and start the process, and will authenticate with other regulators using a daily network secret. ER3 should generate a pair of public/private keys for signing, and exchange the public keys with ER2 to verify each other's digital signature before the Network Secret Salt Key is available.
[0260] Similar to the above example, R3CIO logs into ER3 using R3App, enters information of ER2, and submits a web form securely to ER3. ER3 gets the preferred signing algorithm (ECDSA-P-384) from ER2, generates a pair of public/private keys for client certificate, and sends a CSR and proposed algorithms to ER2. ER2 notifies R2CIO for a decision, and upon approval by R2CIO, ER2 sends a client certificate to ER3 along with network id and accepted algorithms which are the same as the algorithms between El and E2 for demonstration purpose. ER3 saves the client certificate and private key in a database and on a hard disk to access mTLS endpoints of ER2, and adds a background job to get Network Secret Salt Key.
[0261] In a background process in ER3 to get Network Secret Salt Key, ER3 sends a RPC request to ER2 with data like this: {"cmd": "formr.kem.getsecretsalt length", "networkid": "2b8b5853-..."}. ER2 validates ER3's certificate and responds with data like this: {"secretsaltlength": 64, "network-id": "2b8b5853-..."}. ER2 checks at least one of the KEMs is quantum-resistant. If this condition is not satisfied, ER3 should notify R3CIO to enable a quantum-resistant algorithm, and ends the process. Since the agreed AEAD pipeline constructions are ["AES256-CTR-IV128", "XCHACHA20-POLY1305"], two secret keys will be required. ER3 generates two new KYBER1024 key pairs, and two new ECDH-P-384 key pairs, and sends the public keys to ER2, with pseudo data like this: {"cmd": "formr.kem.exchangekeys-forsecretsalt", "kem": ["KYBER1024", "ECDH-P-
384"], "hashing": "SHA-384", "public-key": [{"kid":"uuid0001-...", "public key":
["ER3b64KyberPubKey4aes...", "ER3b64EcdhPubKey4aes..."]}, {"kid": "uuid0002-...", "public-key": ["ER3b64KyberPubKey4cha...", "ER3b64EcdhPubKey4cha..."] "networkid":"2b8b5853-....
[0262] Upon receipt of the public keys, ER2 validates ER3's certificate, checks the issuance time, and checks wether a Network Secret Salt Key has been sent to ER3 before. A certificate and private key could have been stolen. ER2 should reject the request if the certificate is not new, or the Network Secret Salt Key has been sent to ER3 before. ER2 further checks at least one of the KEMs is quantum-resistant. The request should be rejected if no quantum-resistant KEM is found. In this example all conditions are met, ER2 generates two new pairs of KYBER1024 keys, two new pairs of ECDH-P 384 keys, and uses its private keys and ER3's public keys to derive and concatenate key materials. ER2 derives and saves two secret keys WITH Network Secret Salt Key for future use with the agreed AEAD pipeline. The pseudo code looks like this: skaeswithsalt = HKDF (algorithm=hashes.SHA384(), length=32, salt=secret-salt[:48], info=None).derive(concat-keymaterialaes). skccwithsalt = HKDF (algorithm=hashes.SHA384(), length=32, salt=secret-salt[:48], info=None).derive(concatkeymaterialcc).
[0263] To securely transmit Network Secret Salt Key to ER3, ER2 derives two secret keys from the key materials WITHOUT salt. The pseudo code looks like this: secretkeyaes = HKDF (algorithm=hashes.SHA384(), length=32, salt=None, info=None).derive(concatkeymaterialaes). secret keycc HKDF (algorithm=hashes.SHA384(), length=32, salt=None, info=None).derive(concatkeymaterialcc). ER2 generates two nonces for the AEAD pipeline, and prepares metadata which looks like this: {"timestamp": 1645682157740, "nonces": ["b64NonceAes", "b64NonceChaCha"], "kids": ["", ""]}. ER2 encrypts the Network Secret Salt Key with the AEAD pipeline, sets metadata in a custom header X Formr-Aead, updates a database to indicate the Network Secret Salt Key has been shared with ER3, and composes a response message like this: {"public-key":
[{"kid":"uuid0001-...", "public-key": ["ER2b64KyberPubKey4aes...", "ER2b64EcdhPubKey4aes..."]}, {"kid": "uuid0002-...", "public-key":
["ER2b64KyberPubKey4cha...", "ER2b64EcdhPubKey4cha..."]}], "networkid": "2b8b5853-...", "secret-salt": "b64cipherText"}. ER2 signs the response message with its private signing key corresponding to the public key shared with ER3, and sets the digital signature in a custom HTTP header X-Formr-Signature. ER2 replies with the response message and headers including the custom HTTP headers.
[0264] Upon receipt of the response, ER3 may verify the signature of ER2 using ER2's public key. ER3 may reject the response if the signature is invalid. If the signature is valid, ER3 uses its private keys and ER2's public keys to obtain key materials, concatenates in the sequence of KEM, and derives the secret keys using HKDF and the agreed hashing algorithm without salt. Then ER3 uses the nonces in metadata and the derived secret keys to decrypt the ciphertext and get the Network Secret Salt Key, in the reverse order of the AEAD pipeline. Then ER3 derives the secret keys with Network Secret Salt Key, and saves in a database for future use with the agreed AEAD pipeline. ER3 saves the Network Secret Salt Key in a database to securely derive secret keys with other embodiments in the future.
[0265] Upon saving of secret keys, ER3 checks the existence of certificates issued to ER2, and if a valid certificate does not exist (which is the case in this example), ER3 adds a background job to invite a CSR from ER2. The process to get Network Secret Salt Key ends.
[0266] The process for ER3 to invite a CSR from ER2 is similar to the example between ER1 and ER2. ER2 can use the daily network secret to authenticate with ER3 and get a certificate automatically.
[0267] ER3 can submit a CSR to ER1 to get a certificate and exchange keys in a similar process. Since ER3 has the Network Secret Salt Key now, it can authenticate with ER1 and any other embodiments in the network using the daily network secret without waiting for manual approvals.
Methods to Rotate Client Certificates and API Keys, Secret Keys
[0268] It is recommended to rotate client certificates, API keys and secret keys on a regular basis. The secret keys associated with an AEAD using short nonces should be rotated more often.
[0269] To rotate client certificates and API keys, an embodiment sends a RPC request formr.cca.invite-csr to other embodiments to trigger the rotation process. This can be scheduled as a cron job to execute at regular intervals.
[0270] A client certificate is associated with an API key, and should be rotated together. An API key could be sent to a fake server during incidents of internet hijacking. A stolen client certificate could be used to connect to the web server. If the associated API key is not provided, the certificate and the API key should be revoked immediately. An API key can be revoked in real time to deny access without restarting or reloading the configurations of the reverse proxy server. In this case, an embodiment can invite a CSR from the victim embodiment to get replacement certificate and API key.
[0271] To rotate secret keys, an embodiment sends a RPC request formr.kem.exchangekeys-foraead to other embodiments and exchanges new public keys. Each embodiment will derive key materials from exchanged keys, and use a HKDF with the agreed HMAC algorithm and Network Secret Salt Key to derive new secret keys.
[0272] Daily network secret and indexed network secret keys are derived from the Network Secret Salt Key for authentication during the key rotation process. If a Network Secret Salt Key is compromised, some secret keys could have been compromised too. In this case it is better to create a new Network Secret Salt Key and securely share with other embodiments by exchanging public keys using at least one quantum-resistant algorithm, and encrypting the newly created Network Secret Salt Key with keys derived from the new key materials.
Deployment of an embodiment
[0273] For best security, it is recommended to deploy an embodiment on premise, if the premise has facilities equivalent to a data centre, and legacy systems can be containerised. Alternatively an embodiment for a regulator can be deployed in a data centre exclusively for government agencies. It is not recommended to deploy an embodiment in a public cloud. If there is no other option, the cluster API servers managing cluster secrets should run on dedicated servers, and the cluster should use a private network separated from others.
[0274] FIG 1 illustrates a FORMR Network with different scenarios of deployment in a data centre, the interaction with other embodiments and client devices, and cyber security threats. An embodiment may access registration/compliance systems through API over the internet as in the case of Regulator 1. It may cause legacy systems to be accessed over the internet when the legacy systems are deployed to run in the same cluster as the embodiment in a data centre, as in the case of Regulator 2. For regulators who are using paper-based systems, they may use custom modules of the embodiment to manage registration and compliance, and access the modules over the internet, as in the case of Regulator 3.
[0275] Some jurisdictions have strong privacy laws limiting what information regulators can share with other regulators. It is necessary for registered workers to authenticate in a portal and give consent to share private information with selected recipients. Other stakeholders such as potential employers may also authenticate in the portal and have limited access to the information shared with them.
[0276] Neither officers nor stakeholders need to have an account with other regulators or in a centralised system. They authenticate with a server computer of an embodiment in their jurisdiction, and access or manage information according to their roles and privileges. Embodiments authenticate with each other via client certificates and encryption using shared secret keys, and exchange data with organisational authority under an MRA.
[0277] As a result of exchanging data, the regulators' systems have to be exposed to the internet and have to defend against cyber attacks. Web clients and client devices have to use DNS services and IP address to consume APIs, and are potentially victims of internet hijacking.
[0278] During a BGP/DNS hijacking incident, an attacker may tamper with IP address routing or DNS resolution (150, 151), set up a fake server (151, 161), request a SSL/TLS server certificate to be issued by a well trusted Certificate Authority, and steal credentials and data sent to the fake server over asymmetrically encrypted connection following HTTPS protocol.
[0279] When a web client connects to a web server over the internet, it is common for the web client to provide authentication credentials to gain access to the server. When human users log in to a system, the web server may implement multi-factor authentication, by asking for what users know (eg user name and password), and what users have (eg a one-time password derived from a shared secret key, valid for a short period of time). When users have logged in, the web server will issue authentication cookies or tokens, and will authenticate subsequent web requests by examining the cookies or tokens. When a web client accesses API endpoints, it is common to authenticate by an API secret issued by the web server beforehand. Both cookies, tokens and API secrets are presented as plaintext.
[0280] When a web client connects to a web server using HTTPS protocol, it validates the validity of the server certificate, negotiates an encryption algorithm, and encrypts the web request with a key derived from the server's public key. The web server decrypts the web request with a key derived from its private key. In reality, server certificates are valid for a period of time only and are renewed from time to time. During an incident of BGP/DNS hijacking, the web client will trust server certificates issued by a well trusted Certificate Authority (CA), and may unknowingly send credentials and confidential data to a wrong server. The attacker may use the stolen credentials (eg API secrets) to steal more confidential data, or tamper with the systems and data. This is the problem threatening the cyber security of all regulators exchanging data with APIs.
[0281] In at least one of the embodiments, the embodiment enables CCA for the APIs it provides, and for the registration/compliance systems running in the same cluster, as in the cases of Regulator 2 and Regulator 3 in FIG 1. The client certificate and private key bundles are downloaded from the X.509 Client Certificate Issuer component, installed on client devices (132, 142), and validated by the Ingress Controller component of FORMR.
[0282] In at least one of the embodiments, the embodiment uses two different hostnames for the same web service, and enables CCA on one hostname intended for users of high privileges in the system, such as the regulator's officers and employers who have access to the records of multiple registered workers. The officers and employers may install client certificates on their devices (122, 132, 142, 124, 134, 144) beforehand with the help from their IT team. Stakeholders of low privileges (for example the individual registered workers 123, 133, 143) access the web server through a hostname without CCA. Embodiments also use the hostname without CCA to create or join a network by submitting a CSR.
[0283] In a hypothetical scenario, an attacker makes unauthorised changes to DNS records, sets up a fake server and obtains a server certificate from a trusted CA while a regulator's officers are editing confidential records. A client application of the embodiment is not aware of the attack. It will establish a new connection with the fake server, and send requests along with authentication cookies/token to the fake server. An attacker will receive encrypted data from the client application, but will not be able to access the confidential records without the personal session secret keys.
[0284] CCA will not prevent client devices from sending web requests to a fake server during a BGP/DNS hijacking incident. Data is not updated on the real server. For this reason, in at least one of the embodiments, the embodiment will alert officers via a separate communication channel to temporarily stop using the systems if the self monitoring results are abnormal.
Methods to securely exchange data between embodiments
[0285] As explained earlier in the specification, an embodiment should always exchange symmetrically encrypted data with other embodiments and with client devices. It should exchange keys with client devices using a quantum-resistant algorithm. It should monitor DNS/BGP status and submit credentials only when it is safe to do so when it pulls information from a third party system. It should never push plaintext data anywhere.
[0286] Embodiments should support API authentication with a network AEAD pipeline and a Daily Network Secret or a dynamic encryption key for the request. This enables automatically rotating the client certificates, API keys and shared secret keys.
[0287] Each embodiment should provide a configurable option to accept or deny API requests from another embodiment.
[0288] FIG 2 illustrates the information flow between two embodiments on a FORMR network. In both embodiments, an embodiment is accessible via a load balancer, which has an IP address associated with the published domain names. In one embodiment (the embodiment of Regulator A, ERA), the officers set up the schemas of the documents in the embodiment, how the documents from legacy systems map to documents in the embodiment, and how documents in the embodiment map to a schema agreed upon for sharing with the embodiment of regulator B (ERB). Each embodiment should provide configurable options to map data received through API to its internal data structure.
[0289] The officers define action trigger conditions 213a, and the actions to take when a condition is met. A BGP monitor (205a) collects information about BGP announcements from Autonomous Systems (AS) in the world regarding the IP address of the load balancer (221a), and the IP addresses of the regulator's registration/compliance systems. A DNS monitor 216a checks the resolutions of domain names from local DNS resolvers and well known global DNS resolvers. The monitors write monitoring results to a storage component 206a for other components to take appropriate actions. If the self-monitoring results are abnormal, ERA can alert officers of Regulator A, and notify other embodiments in the network through API.
[0290] A Queue Handler 207a watches the queues 210a for tasks to pull data from registration/compliance systems 200a. When there is a task in queue 210a to pull data, it checks the monitoring results in 206a, and puts the task back to the queue 210a after a delay to retry later, if the monitoring results are abnormal. When the monitoring results are normal, it requests new/updated records from registration/compliance system 200a. The records are mapped to the embodiment document schema through data import mapper 211a and saved in database storage 212a. If the records match a predefined trigger condition, the defined actions are carried out, for example, pushing data to ERB.
[0291] To authorise sharing of personal information, a worker registered with Regulator A logs into ERA using a client application (ERAApp). ERAApp exchanges public keys with an ERA web server and derives personal session secret to encrypt communication. It fetches a list of regulators under an MRA from ERA, and renders a user interface for the worker. Upon the worker chooses Regulator B, ERAApp submits the choice to ERA, fetches a list of potential employers registered with Regulator B, and renders the list as options for the worker to select. ERA may fetch the list of employers from ERB if it does not have the list in cache. The worker can optionally select potential employers as recipients of personal information. Upon the worker gives content to share personal information with Regulator B and makes mandatory statements in order to work in the jurisdiction of Regulator B, ERAApp submits the information to ERA. ERA encrypts the personal information and statements with an AEAD pipeline agreed with ERB, pushes to ERB immediately, and on failure, added to queue 215a for retry.
[0292] The queue handler 207a watches tasks in queue 215a, encrypts with an agreed AEAD pipeline, and pushes data to ERB. On failure, it adds the tasks back to queue 215a for retry later. When ERB receives the shared data, it decrypts with the AEAD pipeline (in reverse order), maps to the local document schema to save in a database, grants access to the selected employers, and notifies officers/employers if the data meets trigger conditions. ERB should reply with an encrypted response, and include the request nonce in the metadata in a custom header X-Formr-Aead.
[0293] FIG 3 illustrates a recurring process of pulling information from registration/compliance systems (legacy systems) using API credentials, and pushing information to another embodiment with symmetric encryption. In step 302, if the BGP/DNS monitoring results are abnormal, API credentials might be sent to a fake server, so the process needs to be aborted. If the monitoring results are normal, the embodiment pulls data from legacy systems, converts to a configurable document schema in the embodiment for data persistence, and checks predefined action triggers in step 305. If there is a matching trigger condition, it pushes encrypted data to Regulator B, or adds to a queue for retry upon failure.
[0294] If the registration/compliance systems are on premise, a proxy component deployed on premise authenticates a token encrypted with an AEAD operation with metadata including a nonce submitted in a custom header X-Formr-Aead. It rejects the request if the timestamp in the metadata does not match, or the token can not be decrypted. Upon authentication, the proxy component generates a new nonce, encrypts data with an AEAD operation before replying to the request. The nonce from the request should be included in the metadata of the response for traceability.
[0295] FIG 4A illustrates the login authentication process of a web service in embodiment with CCA enabled. CCA is recommended for all privileged users, such as officers and employers who have access to records of multiple registered workers. Each embodiment should provide a downloadable certificate and key bundle to make it easier to roll out CCA on client devices, for example by importing into a browser. After CCA is enabled, a private key and valid certificate are required to connect to the web service. In use cases where mobile phones and removable media are not allowed, a client certificate may serve as a second authentication factor in addition to password.
[0296] During incidents of BGP hijacking, some officers can still log into a web service using a client application, if these officers are on a network not affected by the tampered BGP routing. Some victimised client devices may still send username and passwords to a fake server, but an attacker can not use these stolen credentials alone to authenticate with a web service. However if the client devices are compromised, some private keys and client certificates could be stolen too. Therefore in step 404, each embodiment should check whether the certificate holder matches the user name provided, and rejects the request in case of mismatch. An embodiment should act as a private CA, and issue a separate certificate to each individual user. Each user should log in using their own certificate.
[0297] If the login authentication is successful, web server issues an encrypted cookie to use as one of the post-login authentication factors.
[0298] FIG 4B illustrates the post-login authentication process of a web service with CCA enabled. As explained earlier in the specification, a client application exchanges public keys with a web server to derive a personal session secret during the login process. The personal session secret stays on the client device, and is never sent back to the server. The client application and the web server then exchange data encrypted with this personal session secret. Thus after a successful login, web server uses three factors for authentication - a valid client certificate, an encrypted session cookie, and symmetric encryption with personal session key. In case both the certificate and the session cookie have been stolen, the symmetric encryption protects data confidentiality and integrity, and enables a web server to detect abnormality and terminate user sessions.
[0299] It is important to note that the personal session secret is protected by the same origin security policy implemented in modern browsers. It is always critical to keep user devices protected from virus and unauthorised access.
[0300] FIG 5 illustrates the login process of a web service without CCA. It is not feasible to securely distribute client certificates remotely and import to stakeholders' devices, for example to registered workers and micro businesses owners who are not tech savvy. An embodiment may serve public pages over a hostname without CCA, so that the stakeholders may connect to a web service in the normal way. Such a web service is required for micro business owners to login and download and install a certificate bundle before using CCA-enabled web services.
[0301] As explained earlier in the specification, a web server derives a personal session secret during the user login process, and issues an encrypted cookie upon successful login. Unlike a cookie, the personal session secret stays on the user device, and is never sent back to the server. In case the encrypted cookie is sent to a fake server and stolen during incidents of internet hijacking, symmetric encryption protects data and enables web server to detect abnormality. For web services without CCA, the personal session secret is a second authentication factor in addition to cookies. Each embodiment should provide a configurable option to disable login by users of certain roles (eg employers) in step 503 when BGP/DNS monitoring results are abnormal. Privileged users such as officers should always login using CCA-enabled hostname. Employers who have access to multiple individuals' records should login using CCA-enabled hostname.
[0302] It is possible that users' device will send login credentials and second authentication factor such as time-based one-time password (TOTP) to a fake server during internet hijacking. An attacker may use these stolen credentials to impersonate users. An embodiment should check and disable login by privileged users using a hostname without CCA. Each embodiment should offer options for users to download certificate bundle, and always use CCA-enabled hostname to login to protect privacy and safety.
[0303] FIG 6a illustrates the process for a registered worker to give consent to share personal information on a client device. A client application should always encrypt data in step 606, and set metadata in a custom header X-Formr-Aead before submitting data to a server. A web server should always respond with encrypted data and set metadata in the custom header X-Formr-Aead too. In step 608, a client application should alert the user if the response from the server is not encrypted, or can not be decrypted. A failure to decrypt indicates the client application may have sent the request to a fake server.
[0304] FIG 6b illustrates the process on the server to handle worker's request to share personal information. During a user session, for each incoming request from a client application, a web server should check a client certificate if enabled, validate an encrypted cookie, and authenticate the encrypted data and the metadata in the custom header X-Formr-Aead with the AEAD operation. It should respond with encrypted data and metadata to the client application in step 657.
[0305] When an embodiment pushes data to another embodiment, it should encrypt data with the agreed AEAD pipeline, send data along with metadata in the custom header X Formr-Aead, and check the encrypted response with the AEAD pipeline in reverse order. A failure to decrypt the response indicates the data may have been sent to a fake server, and it should retry later.
[0306] FIG 7 illustrates the process of pushing data to another embodiment in a background process. A task handler runs on one or more machines. Before making a request, it should check the existence of a client certificate and private key on the local hard disk, and retrieve and save these files if necessary. These files are required to access the endpoints of another embodiment protected with mutual authentication. It should always encrypt data with the agreed AEAD pipeline, and authenticate the response by decrypting it and compare the request nonce in step 704. If a task handler can not decrypt a response, it should retry the job after a delay. A failure to decrypt the response means the data may have been sent to a fake server.
[0307] FIG 8 illustrates the process of receiving data from another embodiment. The APIs to receive data in an embodiment are protected with three factors - client certificates, API key, and AEAD pipeline. Upon receipt of the request, an embodiment should check the certificate holder matches the API key. A request with mismatched certificates and API keys should be rejected as the credentials may have been stolen. It is important to check the timestamp in the metadata from the custom header X-Formr-Aead, and discard requests with old timestamps. Before processing a request, an embodiment should also check logs and discard the request if the request has been processed before. If there are multiple nonces in the request, the first nonce should be checked. Data should be processed only after a request has passed all checks.
[0308] An embodiment should decrypt the received data with the agreed AEAD pipeline, and reject the request if the data is not encrypted or can not be decrypted. An AEAD pipeline is an important authentication factor. Disabling this check jeopardises the data integrity of a FORMR Network, as certificates and API keys could have been stolen, and the data in the request could have been forged.
[0309] After processing the data, an embodiment should reply with an encrypted response, and include the request nonces in the AEAD metadata. Other embodiments validate the encrypted responses and the request nonces to confirm successful delivery of data. A mere response code is not adequate.
[0310] FIG 9 illustrates the process of requesting information from another regulator. These requests typically involve personal information that can identify individuals, and the responses often contain confidentially information intended for officers only. Each embodiment should check the client certificate and the user making such requests, and make sure the user has a defined role authorised to view confidential information.
[0311] It is recommended to make such requests using HTTP verb POST, encrypt personal information with an AEAD pipeline and send in the request body. Symmetrically encrypted data is still protected if it is sent to a fake server. However personal information sent as query parameters in the URL will be automatically decrypted by a fake server. This recommendation applies to both client applications making requests with a web server, and the web client which consumes the APIs of other embodiments.
[0312] An embodiment should authenticate the response by decrypting the response and validating the request nonces in the AEAD metadata. A request could have been sent to a fake server during incidents of internet hijacking, and the response could have been forged. Accepting unencrypted response jeopardises the data integrity.
[0313] In case the response can not be decrypted, a web server should respond to the client application with a warning message, and ask the officer to retry later.
[0314] FIG 10 illustrates the process of supplying requested information to another regulator. The requested information is typically confidential in nature. Each embodiment should validate a client certificate, check the API key, and make sure the certificate and the key have not been revoked. The requests should be authenticated by decrypting with the agreed AEAD pipeline. Requests in plaintexts should be rejected.
[0315] If the request passes all checks, the web server retrieves data and updates subscription to push data to the requesting embodiment when new information becomes available. The response should be encrypted with the AEAD pipeline and the request nonce should be included in the AEAD metadata, for the requesting embodiment to authenticate the response.
[0316] FIG 11 illustrates a reference embodiment in a Kubernetes cluster with cluster monitoring and high availability. The reference embodiment is designed to be deployed in a data centre and to pull information from compliance/registrations systems on premise. The Kubernetes cluster consists of 3 dedicated servers as Kubernetes API servers, and 5 worker nodes. All internet traffic goes through a TCP load balancer 1103, which proxies all incoming connections to one of the ingress controller pods 1110 running on worker nodes. An ingress controller provides mutual authentication with client devices, enforces rate limit, and distributes traffic to one of two OpenResty pods 1111. An OpenResty pod has one or more instances of a containerised OpenResty server which runs a Web Application Firewall (WAF) and validates, filters and proxies traffic to one of two web server pods 1112. The web server handles the actual business logic, maps data, encrypts and decrypts data, and manages keys. Two DNS/BGP monitoring pods 1120 listen to BGP announcements and watch out for any unauthorised changes in DNS records. The monitoring results are written to a Redis server 1116, which serves as the central storage unit. The background task handlers 1140 check the monitoring results before pulling information from data sources. The web server checks the monitoring results before accepting user logins. Redis sentinels monitor instances of Redis servers and nominate a new primary instance in case the old primary instance goes down. Data is encrypted and persisted in a Galera cluster 1114, which synchronises replication of data between multiple database server instances. A database proxy server 1113 monitors the health of database servers and distributes connection to healthy database servers. Galera arbitrators 1115 monitor the health of database servers, and vote to decide the primary component in a Galera cluster.
[0317] Cluster monitoring is optional. In the reference embodiment, a cluster of 3 Rancher servers collects the metrics of the Kubernetes cluster and manages the backup of cluster data.
Advantageous Effects of Invention
[0318] The present invention solves the cyber security problem which is the result of decentralised regulators using generic products and services independently and prudently. The present invention avoids the common pitfalls of exchanging confidential data over API using generic products and services. Embodiments of the present invention form a network of decentralised information management systems that match and exchange information securely.
[0319] The first advantage is that an embodiment can protect data confidentiality and integrity when some encrypted data is sent to a fake server during internet hijacking. The encrypted data can be quantum-resistant.
[0320] The second advantage is that an embodiment can protect endpoints with a multitude of factors. It can protect data confidentiality and integrity when some web clients inevitably send credentials to a fake server during internet hijacking, and the stolen credentials are used to access the embodiment.
[0321] The third advantage is that a client computer may verify the integrity of a response message by authenticating and decrypting the encrypted message with an AEAD pipeline. This may prevent decisions or transactions being made using data that has been maliciously tampered with.
[0322] The fourth advantage is that an embodiment can prevent sending third party credentials to a fake server by monitoring BGP/DNS status and submitting credentials only when monitoring results are normal. An embodiment can monitor external internet services and take appropriate actions in real time to mitigate risks. While there are other products and services available to monitor BGP and DNS status, the monitoring result is less useful if mitigative/preventive actions are not taken in realtime. The alerts from such monitoring services may not arrive during unauthorised changes to DNS records or BGP routing. Regulators can not take immediate action either with their legacy systems, generic closed-source software products, or Software As A Service (SAAS) solutions provided by a third party.
[0323] The fifth advantage is that an embodiment can reduce development time and costs, and minimises changes to a regulator's current systems. An embodiment can use configurable data mappers to read data from multiple systems currently in use by regulators. This is a feasible and more cost-effective solution than each regulator modifying their own systems to communicate with each other.
[0324] The sixth advantage is that an embodiment can provide stronger protection against future attempts to decrypt recorded communications. Symmetric algorithms are considered to be relatively secure against attacks by quantum computers. Even if an adversary can break asymmetric algorithms, an embodiment can still provide the same level of protection as if the adversary has stolen the ciphertext by internet hijacking.
[0325] The seventh advantage is that embodiments in a network can use dynamic encryption keys and an AEAD pipeline to mitigate the risks of implementation errors and vulnerabilities to timing attacks in any embodiment, and can defend against other attacks such as chose-plaintext attacks, chose-ciphertext attacks, chosen-key attacks. Industrial Applicability
[0326] The present invention is designed for a 128-bit security level for protecting data in transit and APIs. The systems and methods to access, match and exchange information through API are designed to manage the cyber security of a FORMR Network as a whole. Assuming all regulators under an MRA have a cyber security framework and their existing systems are secure now, their infrastructure is secure, and the cluster, containerisation, and application code are created/written/maintained by people skilled in the art and kept secure, by implementing embodiments following this specification, the regulators would be able to mitigate the increased cyber security risks, maintain secure systems both individually and collectively in the FORMR Network, and protect data in transit against future brute-force attacks with quantum computers.
[0327] This specification uses regulators of occupational registration as examples to explain how the present invention works for organisations. The present invention is not limited to mutual recognition, regulators or occupational registration. The disclosed systems and methods of the present invention can be carried out to build secure information management systems to access, manage and exchange sensitive information over the internet.
[0328] This specification provides full details and the best mode to carry out the invention. The reference to NIST publications and IETF RFCs is to explain the rationale of choosing some algorithms or encryption constructions, and to help readers to make informed decisions when these algorithms or constructions are not in a local cyber security manual.
[0329] Various modifications to these embodiments are apparent to those skilled in the art from the description and the accompanying drawings. The principles associated with the various embodiments described herein may be applied to other embodiments. Therefore, the description is not intended to be limited to the embodiments shown along with the accompanying drawings but is meant to provide the broadest scope, consistent with the principles and the novel and inventive features disclosed or suggested herein. Accordingly, the disclosure is anticipated to hold on to all other such alternatives, modifications, and variations that fall within the scope of the present disclosure and appended claims.
[0330] In the claims which follow and in the preceding description of the present disclosure, except where the context requires otherwise due to express language or necessary implication, the word "comprise" or variations such as "comprises" or "comprising" are used in an inclusive sense, i.e., to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention.
[0331] Any one of the terms: including or which includes or that includes as used herein is also an open term that also means including at least the elements/features that follow the term, but not excluding others. Thus, including is synonymous with and means comprising.

Claims (14)

  1. The Claims Defining the Invention are as Follows 1. A computer-implemented method for a client computer to securely exchange data with a server computer, the method performed by the client computer, the method comprising:
    storing a client AEAD pipeline comprising a symmetric encryption construction required by the server computer, a symmetric encryption construction required by the client computer, the client AEAD pipeline ending with a client authenticated encryption with associated data (AEAD) construction;
    storing a client secret key associated with each encryption construction of the client AEAD pipeline and identified by a client key identifier, each client secret key for the client AEAD pipeline being securely shared between the server computer and the client computer;
    initiating a request of multiple encryption to the server computer, the request comprising:
    a first request identifier identifying the request,
    request ciphertext representing request payload, the request ciphertext being generated based on the client AEAD pipeline,
    request metadata associated with the request payload and including each client key identifier for the client AEAD pipeline, and
    request authentication information authenticating the request ciphertext and the request metadata, the request authentication information being generated with the client secret key for the client AEAD encryption construction of the client AEAD pipeline, the request being encrypted with a Transport Layer Security (TLS) protocol;
    receiving a response to the request of multiple encryption from the server computer, the response being encrypted with the TLS protocol;
    decrypting the response with the TLS protocol to obtain
    response ciphertext representing response payload,
    response metadata associated with the response payload and comprising a second request identifier and each server key identifier for a server AEAD pipeline, each server key identifier identifying each server secret key for a server AEAD pipeline, the server AEAD pipeline including the symmetric encryption construction required by the server computer, the symmetric encryption construction required by the client computer, ending with a server AEAD construction, and response authentication information; extracting the second request identifier from the response metadata; comparing the second request identifier with the first request identifier; if the second request identifier matches the first request identifier, retrieving each server key identifier for the server AEAD pipeline from the response metadata to obtain each server secret key for the server AEAD pipeline, identifying each encryption construction of the server AEAD pipeline corresponding to each server key identifier, if the response ciphertext and the response metadata is authenticated with the response authentication information based on the server AEAD construction of the server AEAD pipeline and the server secret key for the server AEAD construction of the server AEAD pipeline, decrypting the response ciphertext with the server AEAD pipeline to obtain the response payload.
  2. 2. A computer-implemented method for a server computer to securely exchange data with a client computer, the method performed by the server computer, the method comprising:
    storing a server AEAD pipeline comprising a symmetric encryption construction required by the server computer, a symmetric encryption construction required by the client computer, the server AEAD pipeline ending with a server authenticated encryption with associated data (AEAD) construction;
    storing a server secret key associated with each encryption construction of the server AEAD pipeline and identified by a server key identifier, each server secret key being securely shared between the server computer and the client computer;
    receiving a request of multiple encryption from the client computer encrypted with a Transport Layer Security (TLS) protocol; decrypting the request with the TLS protocol to obtain a request identifier, request ciphertext representing request payload, request metadata associated with the request payload, and request authentication information authenticating the request ciphertext and the request metadata, the request metadata comprising each client key identifier for a client AEAD pipeline; retrieving each client secret key with each client key identifier; identifying each encryption construction of the client AEAD pipeline; if the request ciphertext and the request metadata is authenticated with the request authentication information, decrypting the request ciphertext with the client AEAD pipeline to obtain the request payload; and replying to the client computer with a response comprising response ciphertext representing response payload, response metadata associated with the response payload, the response metadata comprising the request identifier and each server key identifier for the server AEAD pipeline, and response authentication information authenticating the response ciphertext and the response metadata, the response ciphertext being a result of encrypting the response payload with the sever AEAD pipeline, the response being encrypted with the TLS protocol.
  3. 3. A computer-implemented method for a client computer to securely share secret keys with a server computer:
    storing an AEAD pipeline comprising a symmetric encryption construction required by the server computer, a symmetric encryption construction required by the client computer, the AEAD pipeline ending with a client AEAD construction;
    storing a Network Secret Salt Key securely shared between the client computer and the server computer;
    storing a hashing algorithm for both the client computer and the server computer;
    storing a collection of key encapsulation mechanisms (KEM), the KEM collection comprising a client KEM required by the client computer, and a server KEM required by the server computer; for each encryption construction of the AEAD pipeline, generating a pair of client private and public keys with each KEM in the collection of KEMs; deriving an indexed secret key using a key derivation function (KDF) and the hashing algorithm for each encryption construction of the AEAD pipeline, parameters of the KDF including the Network Secret Salt Key as input key material, and a string comprising an exchange time and a sequence number indicating a symmetric encryption construction in the AEAD pipeline; encrypting request payload with each indexed secret key for the AEAD pipeline to obtain request ciphertext, the request payload comprising each client public key for the collection of KEMs; generating request authentication information authenticating the request ciphertext based on the AEAD encryption construction of the AEAD pipeline; initiating a request to the server computer, the request comprising a first request identifier, the request ciphertext representing the request payload, and the request authentication information, the request being encrypted with a TLS protocol; receiving a response from the server computer; decrypting the response with the TLS protocol to obtain response ciphertext representing response payload, response metadata comprising a second request identifier, and response authentication information authenticating the response ciphertext and the response metadata; comparing the first request identifier with the second request identifier; if the second request identifier matches the first request identifier, and the response ciphertext and the response metadata is authenticated with the response authentication information based on the indexed secret keyfor the AEAD construction of the AEAD pipeline, decrypting the response ciphertext with each indexed secret key for the AEAD pipeline to obtain the response payload; parsing the response payload to obtain a collection of server public keys; deriving input key material of the KDF from the collection of server public keys and each client private key; and deriving a shared secret key for each encryption construction in the AEAD pipeline using the KDF and the hashing algorithm with the Network Secret Salt Key as salt of the KDF.
  4. 4. The computer-implemented method of claim 3, wherein the first request identifier is a nonce or a collection of nonces used in the AEAD pipeline.
  5. 5. The computer-implemented method of claim 4, wherein the client computer sends a client certificate to the server computer to establish a TLS-encrypted connection with the server computer, and the request further comprising an API key associated with the client certificate.
  6. 6. The computer-implemented method of claim 1, wherein the first request identifier is a nonce or a collection of nonces used in the client AEAD pipeline selected by the client computer.
  7. 7. The computer-implemented method of claim 1, wherein the request metadata further comprising a request URL and a HTTP method.
  8. 8. The computer-implemented method of claim 1 wherein the client computer sends a client certificate to the server computer to establish a TLS-encrypted connection with the server computer, and the request further comprising an API key associated with the client certificate.
  9. 9. A computer-implemented method for a server computer to securely share secret keys with a client computer:
    storing an AEAD pipeline comprising a symmetric encryption construction required by the server computer, a symmetric encryption construction required by the client computer, the AEAD pipeline ending with a client authenticated encryption with associated data (AEAD) construction;
    storing a Network Secret Salt Key securely shared between the client computer and the server computer;
    storing a hashing algorithm for both the client computer and the server computer; storing a collection of key encapsulation mechanisms (KEM), the KEM collection comprising a client KEM required by the client computer, and a server KEM required by the server computer; receiving a request from the client computer, the request being encrypted with a TLS protocol; decrypting the request with the TLS protocol to obtain request identifier, request ciphertext representing request payload, and request authentication information authenticating the request ciphertext; identifying each encryption construction in the AEAD pipeline; deriving an indexed secret key using a key derivation function (KDF) and the hashing algorithm for each encryption construction in the AEAD pipeline, parameters of the KDF including the Network Secret Salt Key as input key material of the KDF, and a string comprising an exchange time and a sequence number indicating the encryption construction in the AEAD pipeline; if the request ciphertext is authenticated with the request authentication information, decrypting the request ciphertext to obtain the request payload with the AEAD pipeline using each indexed secret key; parsing the request payload to obtain a collection of client public keys; for each encryption construction in the AEAD pipeline, generating a pair of server private and public keys with each KEM in the KEM collection; deriving input key material of the KDF from the collection of server private keys and each client public key; deriving a shared secret key for each encryption construction in the AEAD pipeline using the KDF and the hashing algorithm with the Network Secret Salt Key as salt of the KDF; constructing response metadata comprising the request identifier; encrypting response payload to obtain response ciphertext with the AEAD pipeline using each indexed secret key, the response payload comprising each server public key generated with the KEM collection; generating response authentication information authenticating the response ciphertext and the response metadata; and responding to the client computer with a response comprising the response ciphertext, the response metadata, and the response authentication information, the response being encrypted with a TLS protocol.
  10. 10. The computer-implemented method of claim 9 wherein the request identifier is a nonce or a collection of nonces received in the request.
  11. 11. The computer-implemented method of claim 10 wherein the server computer requires a client certificate before establishing a TLS-encrypted connection with the client computer, and authenticates the request by a combination of authenticating and decrypting the received ciphertext with the AEAD pipeline, and verifying an API key which is associated with the client certificate and submitted in the request.
  12. 12. The computer-implemented method of claim 2 wherein the request identifier is a nonce or a collection of nonces received in the request.
  13. 13. The computer-implemented method of claim 12 wherein the server computer verifies a request URL and a HTTP method included in the request metadata against the request's HTTP method and endpoint.
  14. 14. The computer-implemented method of claim 13 wherein the server computer requires a client certificate before establishing a TLS-encrypted connection with the client computer, and authenticates the request by a combination of decrypting the received ciphertext with the server AEAD pipeline, and verifying an API key which is associated with the client certificate and submitted in the request.
    15. The computer-implemented method of any of claims 1, 2, 3, 5, 8, 9, 11 or 14, wherein each encryption construction of the selected AEAD pipeline uses a key size of at least 128 bits, and the AEAD construction of a selected AEAD pipeline is selected from a list consisting of XChaCha20-Poly1305 with a nonce size of at least 24 bytes, ChaCha20-Polyl305 with a nonce size of at least 12 bytes, AES-GCM with a nonce size of at least 12 bytes, AES-GCM-SIV with a nonce size of at least 12 bytes, AES OCB with a nonce size of at least 12 bytes, and AES-CCM with a nonce size of at least 12 bytes.
    16. The computer-implemented method of claim 15 wherein an operation mode for each symmetric encryption construction of the selected AEAD pipeline is selected from a list if the construction uses a block cipher, the list consisting of: Galois Counter Mode (GCM); counter with cipher block chaining message authentication code mode (CCM); offset codebook mode (OCB); synthetic initialisation vector mode (SIV); AES GCM-SIV; cipher block chaining mode (CBC); cipher feedback mode (CFB); output feedback mode (OFB); and counter mode (CTR).
    17. The computer-implemented method of claim 16 wherein a cipher is selected from a list for each symmetric encryption construction of the selected AEAD pipeline, the list consisting of ChaCha20, Salsa20, AES, Camellia, CAST5, SEED, SM4, ARIA, Twofish, Serpent, Magma, and Kuznyechik.
    18. The computer-implemented method of claim 1, 2, 3 or 9 wherein the Associated Request Metadata authenticated with the selected AEAD pipeline further comprises a string of random bytes generated by the client computer as salt for each request (Request Salt), and both the client computer and the server computer derive a new symmetric encryption key for each symmetric encryption construction of the selected AEAD pipeline using a selected KDF, the Request Salt and a selected secret key, such that the message of each request is encrypted with dynamic encryption keys to defend against timing attacks.
    19. The computer-implemented method of claim 18, wherein the message is prepended with random bytes, appended with random bytes, and concatenated with a first indicator of one or more bytes representing the number of bytes prepended, and a second indicator of one or more bytes representing the number of bytes appended, and the Associated Request Metadata or the Associated Response Metadata further comprises a key-value pair to represent the number of bytes of each indicator, such that the length of the ciphertext of encrypting the padded message with the selected AEAD pipeline becomes unpredictable.
    20. A computer system comprising:
    (i) a memory that stores one or more computer-executable instructions; and
    (ii) a processor configured to access the memory and execute the computer executable instructions to implement the method of any of claims 1-19.
    1 / 14 Dec 2022
    DNS Authoritative Domain name Fake server to resolver DNS server Registrar steal API key and data 112 111 110 Fake DNS or 151 BGP Routing 150 BGP Routing BGP Routing 101 BGP Routing 100 102 2022283634
    Regulator 1 Regulator 3 Brute Regulator 2 FORMR System FORMR System force FORMR System 120 140 exploits 130 170
    Regulator 2 Regulator 3 Legacy System Customised BGP Routing module Internal access 103 141 131
    Regulator 1 Exploits of Brute Legacy System vulnerabilities force Access by internet 180 exploits 121 170 Brute DNS force resolver exploits 113 170
    BGP routing BGP routing 106 104 BGP routing 105
    R1 W1 B1 R2 W2 B2 R3 W3 B3 W1 122 123 124 132 133 134 142 143 144
    Fake DNS or BGP routing Fake server to steal 160 Login password and Auth cookie 161
    FIG 1A FORMR deployment scenarios, FORMR Network and increased cyber threats
    2 / 14 Dec 2022
    API Server Queue handler Deployments and Secrets Runtime: Encrypted data Secrets encryption key Shared secret at rest 191 Private key 192 Client certificate 193 2022283634
    Regulator FORMR system in data centre 120
    internet
    Firewall
    Work Station Registration Reverse Proxy Secrets encryption key System Server with 197 195 Mutual authentication
    API credentials Shared secret Compliance Private CA key Work System 194 Station 196 198
    Regulator office 190
    FIG 1B FORMR remote deployment and on-premise connector with mutual authentication
    3 / 14 Dec 2022
    Domain name Authoritative Regulator B Regulator A DNS Server registrar Registration/ Registration/ 202 201 compliance compliance System 200a system 200b DNS Resolver DNS Resolver 203 203
    Autonomous System Autonomous System 2022283634
    BGP announcement BGP announcement 204 204
    Data import BGP DNS BGP DNS mapper Monitor Data import Monitor Monitor Monitor 211a 205a mapper 216a 205b 216b 211b
    Action Database Monitor Action trigger storage Monitor Database Status trigger 213a 212a Status storage 206a 213b 206b 212b
    Queue to API Data API Data pull data Queue to mapper pull data mapper 210a 214a 214b 210b
    Queue to Web server push data Queue to 224a Web server 215a push data 224b 215b
    Queue Web app Queue Web app Handler firewall Handler firewall 207a 223a 207b 223b
    Ingress Notification Ingress controller Notification controller 240a 222b 240b 222a
    Regulator A Regulator B FORMR System 299A FORMR System 299B
    Load balancer DNS Resolver Load 203 balancer DNS Resolver 221a 203 221b
    Device of Device of Regulator A Device of Device of Licensed Worker Employer Regulator B Officer Officer 220a 230 250 220b
    FIG 2 Combined BGP/DNS monitoring and information flow between systems
    4 / 14 Dec 2022
    Start
    Fetch a new task to import data from legacy system, and check monitoring status 301
    Is the DNS/BGP status of No, the legacy system normal? abort 2022283634
    302
    yes Submit credentials to pull new and updated data from legacy system 303
    Map data to document model and persist in database 304
    No. Does the document End process match an action trigger to share data? 305
    yes Map data to agreed data sharing protocol, generate nonce, and encrypt with a shared secret key 306
    Send encrypted data to the target server through API 307
    No. Add to queue for retry. Can the server response be decrypted End process with shared secret key and match the nonce? 308
    yes Log successful sharing of data. 309
    End
    FIG 3 Pulling information from legacy system
    5 / 14 Dec 2022
    Start
    Receive a login request at a web host requiring a client certificate 401
    Can the client present a No, valid certificate? deny 2022283634
    402 access yes Is the combination of username and password correct? No, 403 deny access
    yes
    Does the client certificate No, match the username? deny 404 access yes
    No, Can the user provide a required second factor deny for authentication? access 405
    yes
    Create a user session, and issue a random personal session key 406
    Respond with the personal session key 407
    Log successful login 408
    End.
    FIG 4A Login process of web hosts requiring a client certificate
    6 / 14 Dec 2022
    Start
    Receive a web request at a web host requiring a client certificate 451
    Can the client present a No, 2022283634
    valid certificate? deny 452 access yes Does the request include a valid authentication cookie that can be decrypted? No, 453 deny access
    yes
    Is there a valid session No, On the server? deny 454 access yes
    Does the user have a role defined in No, Access Control Level for this data type and operation? deny 455 access
    yes
    Decrypt data with the private session key. 456
    Process data, and respond with data encrypted with the personal session key 457
    Log successful access 458
    End.
    FIG 4B Access control of web hosts requiring a client certificate
    7 / 14 Dec 2022
    Start
    Receive a login request 501
    Is the DNS/BGP status of the service normal? 2022283634
    502 yes no
    Is the role allowed to login No, when DNS/BGP might have be tampered? Deny 503 access yes
    Is the password correct? No, 505 deny access yes
    No, Is the second factor authentication correct? deny 506 access
    yes
    Issue a private session key, grant access to data 507
    Log successful login. 508
    End
    FIG 5 Access control of authentication endpoints with low privileges
    8 / 14 Dec 2022
    Start
    Render user interface in client app for the user to choose recipients of personal information (a regulator in another jurisdiction and optional employer) 601
    Display message and ask the user to agree to 2022283634
    share personal information with selected recipients 602
    Has the user agreed to No, share personal information? Abort 604 action yes Prevent web form default behaviour, collect form data 605
    Encrypt form data with the personal session key 606
    Send encrypted data to the server 607
    Can the server response be decrypted No. Alert the with the personal session key? user to retry later. 608 yes Provide success feedback to user. 609
    Log successful sharing of data. 610
    Process ends.
    FIG 6a Client application process of sharing personal information with selected recipients
    9 / 14 Dec 2022
    Start
    Receive user request on server, and validate authentication cookies 650
    Can the secure cookie be decrypted No, with cookie key? remove 2022283634
    651 auth cookie and redirect yes Can the request be decrypted No, with the personal session key? remove 652 auth cookie yes and redirect
    Retrieve registration data and shared regulator secret key from storage 653
    Map data to agreed data sharing protocol, generate nonce, and encrypt with regulator shared secret key 654
    Send encrypted data to the target regulator’s server through API 655
    Can the server response be decrypted No. Add to with shared secret key and match the nonce? queue for retry. Provide feedback 656 to user. yes Provide success feedback to user. 657
    Log successful sharing of data. 658
    Process ends.
    FIG 6B Server application process of sharing personal information with selected recipients
    10 / 14 Dec 2022
    Start
    Fetch a task from queue 700
    Retrieve data from storage 701 2022283634
    Map data to agreed data sharing protocol, generate nonce, and encrypt with shared secret key 702
    Send encrypted data to the target server through API 703
    No. Add to queue for retry. Can the server response be decrypted End process with shared secret key and match the sent nonce? 704
    yes Log successful sharing of data. 705
    Process ends.
    FIG 7 Processing queue and pushing data to another regulator
    11 / 14 Dec 2022
    Start
    Receive encrypted data from another regulator through API 800
    Retrieve shared secret key from storage, decrypt data, find nonce, and check logs of processed requests. 2022283634
    801
    Can the data be decrypted No. end process with shared secret key and the nonce received is not in the log of processed requests? 802
    yes Map data to document model to persist in database 803
    Make the record accessible to selected employer, and notify the employer 804
    Notify officers if the document matches defined event triggers 805
    Log successful processing of data. 806
    Encrypt the received nonce with shared secret key and acknowledge successful receipt of data 807
    Process ends.
    FIG 8 Processing data received from another regulator through API
    12 / 14 Dec 2022
    Start
    Render user interface in a browser for authenticated officers to request law enforcement information from another jurisdiction 901 2022283634
    Receive and validate user request on server 902
    Is the user authorised to request No, such information on demand? redirect to 903 error page yes Retrieve shared secret key from storage, generate nonce, and encrypt data request with shared secret key 904
    Send encrypted request to the home regulator’s server through API 905
    No. redirect to Can the server response be decrypted error page. with shared secret key and match the nonce? 906
    yes Map received data to document model and persist in database. Notify other officers as per defined trigger conditions. 907
    Log successful on-demand request 908
    Provide feedback to user 909
    Process ends.
    FIG 9 Pull information on demand from another jurisdiction
    13 / 14 Dec 2022
    Start
    Receive encrypted request from another regulator through API 1000
    Retrieve shared secret key from storage, decrypt data, find nonce, and check logs of processed requests. 2022283634
    1001
    Can the data be decrypted No. end process with shared secret key and the nonce received is not in the log of processed requests? 1002
    yes Retrieve requested data 1003
    Update or stop subscription for future updates of shared documents 1004
    Map data to a format as per agreed data sharing protocol 1005
    Log successful processing of request. 1006
    Reply with data and the received nonce encrypted with shared secret key 1007
    Process ends.
    FIG 10 Processing data request from another regulator
    14 / 14 Dec 2022
    Optional Kubernetes Kubernetes Kubernetes Load Api Server Api Server Api Server Balancer Rancher Rancher Rancher 1100 1101 1101 1101
    Optional cluster for monitoring by rancher 2022283634
    Kubernetes Api Server, Kubernetes Api Server, Kubernetes Api Server, Info from Deployments Secrets Deployments Secrets Deployments Secrets Other 1106 1106 1106 Monitored clusters Ingress Redis + Task Ingress Redis + Task Controller Sentinel scheduler Controller Sentinel Scheduler Legacy 1110 1116 1130 1110 1116 1130 System 1102 OpenResty Web Task OpenResty Web Task Web app Server Handler Web app Server Traffic from Handler Firewall 1112 1140 Firewall 1112 Other 1140 1111 1111 jurisdictions
    DNS/BGP Galera Galera DNS/BGP DB Proxy DB Proxy Cluster Monitor Monitor Cluster TCP 1113 1113 1114 1120 1120 1114 Load Balancer 1103 Persistent volume Persistent volume
    DNS Ingress Galera Ingress Galera Ingress Galera Resolver Controller Arbitrator Controller Arbitrator Controller Arbitrator 1104 1110 1115 1110 1115 1110 1115 Galera Redis + Galera Redis Galera Redis + Cluster Sentinel Cluster Sentinel Cluster Sentinel 1114 1116 1114 1116 1114 1116 Internet Persistent volume Persistent volume Service Persistent volume Provider BGP routing High Availability FORMR Setup 1105
    Officer Employer Worker device device device
    FIG 11 Reference embodiment of FORMR with optional cluster monitoring
AU2022283634A 2022-03-04 2022-12-05 System and method for exchange of data and/or secret keys Abandoned AU2022283634A1 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
AU2022900535A AU2022900535A0 (en) 2022-03-04 System and methods to securely exchange data
AU2022900535 2022-03-04
AU2022901865A AU2022901865A0 (en) 2022-07-01 Systems and Methods to Securely Exchange Data
AU2022901865 2022-07-01

Publications (1)

Publication Number Publication Date
AU2022283634A1 true AU2022283634A1 (en) 2023-09-21

Family

ID=88019522

Family Applications (1)

Application Number Title Priority Date Filing Date
AU2022283634A Abandoned AU2022283634A1 (en) 2022-03-04 2022-12-05 System and method for exchange of data and/or secret keys

Country Status (1)

Country Link
AU (1) AU2022283634A1 (en)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060210080A1 (en) * 2003-11-17 2006-09-21 Koninklijke Philips Electronics N.V. Key synchronization in a visual cryptographic system
US7571321B2 (en) * 2003-03-14 2009-08-04 Voltage Security, Inc. Identity-based-encryption messaging system
US8448235B2 (en) * 2010-08-05 2013-05-21 Motorola Solutions, Inc. Method for key identification using an internet security association and key management based protocol
US10033703B1 (en) * 2015-06-16 2018-07-24 Amazon Technologies, Inc. Pluggable cipher suite negotiation
US11063758B1 (en) * 2016-11-01 2021-07-13 F5 Networks, Inc. Methods for facilitating cipher selection and devices thereof
US20210281404A1 (en) * 2020-03-04 2021-09-09 Cisco Technology, Inc. Communication latency based cryptographic negotiations

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7571321B2 (en) * 2003-03-14 2009-08-04 Voltage Security, Inc. Identity-based-encryption messaging system
US20060210080A1 (en) * 2003-11-17 2006-09-21 Koninklijke Philips Electronics N.V. Key synchronization in a visual cryptographic system
US8448235B2 (en) * 2010-08-05 2013-05-21 Motorola Solutions, Inc. Method for key identification using an internet security association and key management based protocol
US10033703B1 (en) * 2015-06-16 2018-07-24 Amazon Technologies, Inc. Pluggable cipher suite negotiation
US11063758B1 (en) * 2016-11-01 2021-07-13 F5 Networks, Inc. Methods for facilitating cipher selection and devices thereof
US20210281404A1 (en) * 2020-03-04 2021-09-09 Cisco Technology, Inc. Communication latency based cryptographic negotiations

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
GO-ITS 25.12 Security Requirements for the Use of Cryptography [retrieved from internet on 12 August 2022] <URL: https://web.archive.org/web/20220322215015/ https://www.cyber.gov.au/acsc/view-all-content/advice/guidelines-cryptography> Queensland Government Enterprise Architecture - Data Encryption Standard [retrieved from internet on 12 August 2022] <URL: https://web.archive.org/ web/20220606040205/https://www.qgcio.qld.gov.au/documents/data-encryption standard> *
Guidelines for Cryptography [retrieved from internet on 12 August 2022] <URL: https://web.archive.org/web/20220322215015/https://www.cyber.gov.au/acsc/view-all-content/advice/guidelines-cryptography> *
Queensland Government Enterprise Architecture - Data Encryption Standard [retrieved from internet on 12 August 2022] <URL: https://web.archive.org/web/20220606040205/https://www.qgcio.qld.gov.au/documents/data-encryption-standard> *
SCHNEIER, Bruce, 'Applied Cryptography: Protocols, Algorithms and Source Code in C, 20th Anniversary Edition', Wiley, March 2015, ISBN 978-1-119-09672-6, '15.7 Cascading Multiple Block Algorithms' *

Similar Documents

Publication Publication Date Title
US11588649B2 (en) Methods and systems for PKI-based authentication
JP6625211B2 (en) Key exchange through partially trusted third parties
US20190222583A1 (en) Signed envelope encryption
US20180167219A1 (en) Distributed system web of trust provisioning
JP6731491B2 (en) Data transfer method, non-transitory computer-readable storage medium, cryptographic device, and method of controlling data use
McKay et al. Guidelines for the selection, configuration, and use of transport layer security (TLS) implementations
CN105681470B (en) Communication means, server based on hypertext transfer protocol, terminal
KR20210134655A (en) Security systems and related methods
US9876773B1 (en) Packet authentication and encryption in virtual networks
CN106790090A (en) Communication means, apparatus and system based on SSL
Borselius Multi-agent system security for mobile communication
Hirsch et al. Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML) V2. 0
AU2022283634A1 (en) System and method for exchange of data and/or secret keys
Tan et al. A universal decentralized authentication and authorization protocol based on Blockchain
Diaz et al. On securing online registration protocols: Formal verification of a new proposal
US20210084027A1 (en) A Digitally Certified Ecosystem
JP2005167967A (en) Anonymous communication method
Gilchrist The Concise Guide to SSL/TLS for DevOps
Eteng A Multilayer Secured Messaging Protocol for REST-based Services
Ojamaa et al. Securing Customer Email Communication in E-Commerce
Sharifnia et al. Development of trust model for e-supply chain management applications
AlMahmoud Authentication Layer for Real-Time Business Process Analysis
McKay et al. Release of NIST Special Publication 800-52 Revision 1, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations
Gurbanova Review of the operations over the digital certificates in various cases
Anderson Secure sockets layer certificate vulnerabilities: An examination of challenges affecting authentication of secure websites

Legal Events

Date Code Title Description
MK5 Application lapsed section 142(2)(e) - patent request and compl. specification not accepted