diff --git a/config.toml b/config.toml index 7facf2cc..55ce653a 100644 --- a/config.toml +++ b/config.toml @@ -18,11 +18,11 @@ publishDir = "docs" identifier = "ws" url = "https://www.qrypt.com/" weight = 1 -[[menu.shortcuts]] - name = '
 Qrypt Portal
' - identifier = "ps" - url = "https://portal.qrypt.com/" - weight = 2 +# [[menu.shortcuts]] + # name = '
 Qrypt Portal
' + # identifier = "ps" + # url = "https://portal.qrypt.com/" + # weight = 2 [[menu.shortcuts]] name = " Github Repo" identifier = "gh" diff --git a/content/_index.md b/content/_index.md index 1f2585d5..7662a2e0 100644 --- a/content/_index.md +++ b/content/_index.md @@ -19,14 +19,6 @@ Below is a list of the products that Qrypt offers with links to their supporting ### [Quantum Entropy Appliance (on-prem)](eaas/appliance/) Qrypt's on-prem quantum entropy appliance is a server that is intentended for on-prem deployments. It exposes a REST API that clients can call to retrieve quantum entropy from the QRNG card installed on the server. -### [Quantum Readiness](quantumreadiness/) - -Quantum readiness provides centralized deployment and management UI of all Qrypt products. - -### [Post quantum TLS proxy](postquantumproxy/) - -This post quantum TLS proxy allows for incoming TLS connections to use post quantum cryptography. - ### [Quantum Entropy as a Service](/eaas/) Qrypt's Quantum Entropy service measures quantum effects and converts those measurements into pure random numbers. The service leverages multiple Quantum Random Number Generators (QRNGs) developed in collaboration with national and international research labs to ensure the highest quality random. @@ -34,7 +26,3 @@ Qrypt's Quantum Entropy service measures quantum effects and converts those meas ### [Key Generation](sdk/) Qrypt SDK includes client library SDKs, cloud-based REST services, command line clients and guidance to help integrate post-quantum security into your applications and services. You can add security features to your applications without being an expert in post-quantum cryptography. - -### [Portable OpenSSH with Qrypt](openssh/) - -This implementation of OpenSSH has been modified to provide additional security via the Qrypt Key Generation SDK. During key exchange negotiation, the Qrypt SDK will generate an additional quantum-secure secret that is added to the session key hash inputs. diff --git a/content/eaas/_index.md b/content/eaas/_index.md index 337ccd90..c703dfb6 100644 --- a/content/eaas/_index.md +++ b/content/eaas/_index.md @@ -8,11 +8,12 @@ disableToc = "true" ## Using Qrypt's Quantum Entropy Service -Qrypt’s Entropy as a Service is a RESTful web service that allows you to generate random data (henceforth referred to as entropy or random) that is truly random—based on quantum-mechanical phenomena. +Qrypt’s Entropy as a Service is a RESTful web service that allows you to generate random data (henceforth referred to as entropy or random) that is truly random—based on quantum-mechanical phenomena. -This service requires an access token. Follow the steps in [Getting Started]({{< ref "/getting_started" >}}) to obtain an access token. +This service requires an access token. Please {{< externalLink link="https://www.qrypt.com/contact/" text="contact us" >}} to obtain one. ### Related Tools and Services + 1. [RNG Tools]({{< ref "/eaas/rngd" >}}): Integrating Qrypt's Quantum Entropy service as a random source for system devices. 2. [Qseed]({{< ref "/eaas/pkcs11" >}}): Integrating Qrypt's Quantum Entropy service as a random source for PKCS#11 HSMs. @@ -31,7 +32,7 @@ Follow these steps in your preferred tool or language of choice to request entro 1. Specify your access token and the desired number of kibibytes (1,024 bytes) of entropy in a web request. Use the following URL: {{< externalLink link="https://api-eus.qrypt.com/api/v1/quantum-entropy?size={kib_entropy}" text="https://api-eus.qrypt.com/api/v1/quantum-entropy?size={kib_entropy}" >}}. 2. Replace {**kib_entropy**} in the aforementioned URL with an integer indicating the number of kibibytes of entropy to return. 3. Include an HTTP **“Accept”** header field with a value of **“application/json”**. -4. Include an HTTP **“Authorization”** header with a value of **“Bearer {access_token}”**, where {**access_token**} is the access token obtained from the Qrypt portal. +4. Include an HTTP **“Authorization”** header with a value of **“Bearer {access_token}”**, where {**access_token**} is the access token obtained from the Qrypt portal (contact us to get one). 5. Submit the HTTP request using the HTTP GET method. 6. If the HTTP request is successful, the JSON-formatted response will contain a structure containing two fields named **“random”** and **“size”**. The **“random”** field contains an array of base64-encoded strings (each of which—when decoded—contains 1,024 bytes of entropy). The **“size”** field contains the number of elements in the **“random”** field. @@ -76,7 +77,7 @@ The following illustrates an example of JSON output as returned by a request for ## Examples The following examples demonstrate how to submit a request and display the returned entropy. -In the following examples, _{subdomain}_ should be replaced with the subdomain for a server in the geographic location you would like to use (see Table 2), _{kib_entropy}_ should be replaced with an integer between 1 and 512, and _{qrypt_access_token}_ should be replaced with an access token generated using your Qrypt account. +In the following examples, _{subdomain}_ should be replaced with the subdomain for a server in the geographic location you would like to use (see Table 2), _{kib_entropy}_ should be replaced with an integer between 1 and 512, and _{qrypt_access_token}_ should be replaced with an access token. ## Curl diff --git a/content/eaas/nist/_index.md b/content/eaas/nist/_index.md index 44f9a039..7d264a07 100644 --- a/content/eaas/nist/_index.md +++ b/content/eaas/nist/_index.md @@ -5,13 +5,14 @@ weight = 20 chapter = false +++ - ## Using Qrypt's NIST Entropy Quality Tests -Qrypt’s NIST Entropy Quality Tests is a set of APIs that allows you to check the quality of Qrypt's entropy using the NIST Statistical Test Suite. Tests are conducted every 10 minutes against Qrypt's Quantum Entropy service. Accessing this service does not require a Qrypt account or access token. +Qrypt’s NIST Entropy Quality Tests is a set of APIs that allows you to check the quality of Qrypt's entropy using the NIST Statistical Test Suite. Tests are conducted every 10 minutes against Qrypt's Quantum Entropy service. Accessing this service does not require a Qrypt access token. --- + ## About NIST Entropy Quality Tests + The NIST Entropy Quality Test suite uses the 15 statistical tests defined by the NIST Statistical Test Suite (STS). Each of these 15 tests is repeated over many samples. The APIs generate two test results: 1. **Total number of individual passing tests**: considered successful if a sufficient number of individual tests pass. The threshold varies based on the number of individual tests run and is based on an alpha value of 0.01. For example, 1000 individual tests requires a 98% pass rate to be considered successful. @@ -20,12 +21,15 @@ The NIST Entropy Quality Test suite uses the 15 statistical tests defined by the The tests are considered as succeeding overall if either of these criteria are met. This provides a metric for passing that is more robust to fluctuations than using either criterion alone. However, this standard does not catch certain randomness defects. For example, if the randomness was periodic with a period equal to the size used for batching, a sufficiently high portion of the tests might pass, but the P-values would not be uniform. ## NIST Entropy Quality Test Endpoints -There are three endpoints for obtaining NIST entropy quality test results. + +There are three endpoints for obtaining NIST entropy quality test results. + 1. NIST Logs: retrieves a specified number of recent test results 2. Failing NIST Logs: retrieves a specified number of recent failing test results 3. Failing NIST Random: retrieves random of recent failing tests ### NIST Logs + This API contains the most recent NIST test results. To get NIST test results, you must submit an HTTP request to the API, optionally providing the number of results to view and whether they should be shown in a simplified format. 1. Make a request to the following URL: {{< externalLink link="https://nist.qrypt.com/api/v1/logs?num={num}&simple={simple}" text="https://nist.qrypt.com/api/v1/logs?num={num}&simple={simple}" >}}. @@ -33,14 +37,16 @@ This API contains the most recent NIST test results. To get NIST test results, y 3. Optionally replace {**simple**} with a true or false to specify if you want a simplified test result output. ##### Request Parameters + {{< nist/logs/requestParameters >}} ##### Response Codes + {{< nist/logs/responseCodes >}} ##### JSON Response Fields -For a successful 200 response, the response contains a JSON-encoded structure with an array of test results with the following fields in each array element. Note that the simplified logs only contain 'tests_passed', 'time_of_completion' and 'time_of_completion_string' fields. +For a successful 200 response, the response contains a JSON-encoded structure with an array of test results with the following fields in each array element. Note that the simplified logs only contain 'tests_passed', 'time_of_completion' and 'time_of_completion_string' fields. There are two main groupings of tests. One is prefixed 'nist' for the number of NIST STS tests that passed or failed, and the second is 'uniformity' for the uniformity of each NIST STS test's P-values. @@ -67,19 +73,22 @@ The following illustrates an example of JSON output as returned by a request for ``` ### NIST Failed Test Logs + This API contains the most recent failed NIST test results, where both the individual test rate and uniformity tests fail. To get failed NIST test results, you must submit an HTTP request to the API. 1. Make a request to the following URL: {{< externalLink link="https://nist.qrypt.com/api/v1/failing_logs?num={num}&simple={simple}&strict={strict}&include_random={include_random}&randsize={randsize}" text="https://nist.qrypt.com/api/v1/failing_logs?num={num}&simple={simple}&strict={strict}&include_random={include_random}&randsize={randsize}" >}} 2. Optionally replace {**num**} with the number of recent test results to show. 3. Optionally replace {**simple**} with 'true' to output simplified logs. 4. Optionally replace {**strict**} with 'false' specify if you want to show logs that failed either the test rate or uniformity. -4. Optionally replace {**include_random**} with 'true' to see failed random. Only applicable if 'strict' is 'true'. -5. Optionally replace {**randsize**} with the number of bits to show. Only applicable if 'include_random' is set to 'true'. +5. Optionally replace {**include_random**} with 'true' to see failed random. Only applicable if 'strict' is 'true'. +6. Optionally replace {**randsize**} with the number of bits to show. Only applicable if 'include_random' is set to 'true'. ##### Request Parameters + {{< nist/failing_logs/requestParameters >}} ##### Response Codes + {{< nist/failing_logs/responseCodes >}} ##### JSON Response Fields @@ -109,8 +118,8 @@ The following illustrates an example of JSON output as returned by a request for ] ``` - ### NIST Failed Random + This API contains the random of the most recent strictly failing NIST tests. To get the random of failed NIST test results, you must submit an HTTP request to the API. 1. Make a request to the following URL: {{< externalLink link="https://nist.qrypt.com/api/v1/failing_random?num={num}&randsize={randsize}" text="https://nist.qrypt.com/api/v1/failing_random?num={num}&randsize={randsize}" >}} @@ -118,9 +127,11 @@ This API contains the random of the most recent strictly failing NIST tests. To 3. Optionally replace {**randsize**} with 'true' to output simplified logs. ##### Request Parameters + {{< nist/failing_random/requestParameters >}} ##### Response Codes + {{< nist/failing_random/responseCodes >}} ##### JSON Response Fields diff --git a/content/eaas/pkcs11/_index.md b/content/eaas/pkcs11/_index.md index e3e4baf3..077a50a6 100644 --- a/content/eaas/pkcs11/_index.md +++ b/content/eaas/pkcs11/_index.md @@ -5,15 +5,18 @@ weight = 40 This page covers the [Qseed](https://github.com/QryptInc/qseed) application architecture that downloads quantum entropy from Qrypt's entropy service and injects it into a PKCS#11 compliant HSM (Hardware Security Modules) as seed random. -This service requires an access token. Follow the steps in [Getting Started]({{< ref "/getting_started" >}}) to obtain an access token. +This service requires an access token. Please {{< externalLink link="https://www.qrypt.com/contact/" text="contact us" >}} to obtain one. ## Technology Value + Many of the available HSMs use non-quantum entropy sources. Fortunately, the PKCS#11 Cryptoki interface provides a C_SeedRandom function to inject entropy into a PKCS#11 compliant HSM. Developers can inject Qrypt's quantum entropy into a HSM using the C_SeedRandom function. As a result, HSM keys can be pseudorandomly generated from quantum entropy. ## Overview + {{< figure src="images/inject-seedrandom.png" >}} There are four components to the architecture diagram above. + 1. **Qrypt Services**: Qrypt's entropy service that can provide quantum entropy via a REST API. 2. **Qseed Application**: Application that periodically retrieves entropy from Qrypt's entropy service and injects it into an HSM via a PKCS#11 Cryptoki interface (C_SeedRandom). 3. **Cryptoki Library**: A library that the HSM vendor provides that implements the PKCS#11 Cryptoki interface for their device. @@ -44,4 +47,3 @@ The Qseed application only support Crypto User PINs. You will need to create a C ## References More information about the PKCS#11 Cryptoki interface can be found at [Oasis PKCS#11 Specification](https://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html). - diff --git a/content/eaas/rngd/_index.md b/content/eaas/rngd/_index.md index 72a5a765..786a1ad5 100644 --- a/content/eaas/rngd/_index.md +++ b/content/eaas/rngd/_index.md @@ -8,24 +8,26 @@ disableToc = "true" ## Using Qrypt's Quantum Entropy in RNG Tools -*rng-tools* is a utility that allows you to inject entropy from hardware sources, prngs, and http streams into system devices. Qrypt's Quantum Entropy service is a random source option in *rng-tools*, allowing you to inject quantum entropy into system devices such as '/dev/random', '/dev/urandom', and user-defined nodes or files. +_rng-tools_ is a utility that allows you to inject entropy from hardware sources, prngs, and http streams into system devices. Qrypt's Quantum Entropy service is a random source option in _rng-tools_, allowing you to inject quantum entropy into system devices such as '/dev/random', '/dev/urandom', and user-defined nodes or files. -This service requires an access token. Follow the steps in [Getting Started]({{< ref "/getting_started" >}}) to obtain an access token. +This service requires an access token. Please {{< externalLink link="https://www.qrypt.com/contact/" text="contact us" >}} to obtain one. -More information about *rng-tools* can be found on the {{< externalLink link="https://github.com/nhorman/rng-tools" text="rng-tools Github" >}} and the {{< externalLink link="https://wiki.archlinux.org/title/Rng-tools" text="rng-tools wiki page" >}}. +More information about _rng-tools_ can be found on the {{< externalLink link="https://github.com/nhorman/rng-tools" text="rng-tools Github" >}} and the {{< externalLink link="https://wiki.archlinux.org/title/Rng-tools" text="rng-tools wiki page" >}}. --- ## Installation -To use Qrypt's Quantum Entropy service in *rng-tools*, *rng-tools* must be installed and configured. +To use Qrypt's Quantum Entropy service in _rng-tools_, _rng-tools_ must be installed and configured. + +Clone the latest _rng-tools_ master from GitHub. -Clone the latest *rng-tools* master from GitHub. ```bash git clone https://github.com/nhorman/rng-tools ``` -Install *rng-tools* dependencies. Additional packages may be required, depending on linux distro. The configure script below will name any missing packages it encounters. +Install _rng-tools_ dependencies. Additional packages may be required, depending on linux distro. The configure script below will name any missing packages it encounters. + ```bash sudo apt install \ make \ @@ -41,6 +43,7 @@ sudo apt install \ ``` Add `--disable-dependency-tracking` to the './configure' command if needed. + ```bash ./autogen.sh ./configure @@ -49,11 +52,13 @@ sudo make install ``` Verify installation. + ```bash which rngd ``` ## Command Line Usage + The resulting 'rngd' executable can run directly to start either a daemon or a foreground process. By default, 'rngd' will run as a background daemon and attempt to use the 'hwrng', 'errand', 'pkcs11', and 'rtlsdr' random sources. To run 'rngd' using exclusively Qrypt's Quantum Entropy, run the following command. This will run 'rngd' as a foreground process with the Qrypt source enabled and all other entropy sources disabled. 'rngd' will send its random to the /dev/random device. @@ -68,7 +73,8 @@ Command line options: {{< rngd/rngd-options >}} ## Service Usage -*rng-tools* comes with a 'rngd.service' file for setting up a systemd service. To configure rngd to automatically start the Qrypt source on boot, follow these steps: + +_rng-tools_ comes with a 'rngd.service' file for setting up a systemd service. To configure rngd to automatically start the Qrypt source on boot, follow these steps: Save your Qrypt api token to a system-accessible directory, such as '/etc/rngd/qrypt.token'. Then, edit 'rngd.service' to add Qrypt arguments and options. @@ -90,23 +96,27 @@ WantedBy=multi-user.target ``` Copy the 'rngd' service to systemd. + ``` sudo cp rngd.service /etc/systemd/system/rngd.service sudo chmod 644 /etc/systemd/system/rngd.service ``` Start the 'rngd' service. + ``` sudo systemctl daemon-reload sudo systemctl start rngd ``` Verify the 'rngd' service is running properly. + ``` sudo systemctl status rngd ``` Enable the 'rngd' service for it to start on system boot. + ``` sudo systemctl enable rngd ``` diff --git a/content/faqs/_index.md b/content/faqs/_index.md index 25595ee5..44fd9cfc 100644 --- a/content/faqs/_index.md +++ b/content/faqs/_index.md @@ -6,25 +6,6 @@ weight = 80 disableToc = "true" +++ -**What do I do if I forget my password?** - -Qrypt does not have access to your password, but you can place a request to change your password. - -1. Navigate to the portal at {{< externalLink link="https://portal.qrypt.com" text="https://portal.qrypt.com" >}} and click the “Forgot password?” link. -2. Enter the email address associated with your account and click the “Send me the link” button. -3. Check your email for a message with further instructions. - ---- - -**How do I change my password?** - -1. Navigate to the portal at {{< externalLink link="https://portal.qrypt.com" text="https://portal.qrypt.com" >}} and login to your account. -2. Click the account icon (top-right corner) and select “Account settings.” -3. Click the “Change password” link. -4. Enter your original password, enter a new password, and click the “Change password” button. - ---- - **What should I do with my access token?** Your access token is the mechanism by which your account will be charged for entropy data, and as such, it should be treated as secure and secret information (much as you would treat a password). @@ -33,7 +14,7 @@ Your access token is the mechanism by which your account will be charged for ent **I lost or forgot to save my access token. How can I retrieve it?** -To increase security, Qrypt only displays access tokens when they are first generated. If you have lost your token, you can contact Qrypt sales support at support@qrypt.com or generate a new one. +To increase security, Qrypt only displays access tokens when they are first generated. If you have lost your token, you can contact Qrypt sales support at support@qrypt.com. --- @@ -51,7 +32,7 @@ Once the monthly entropy quota has been reached, quantum entropy service request **I need more entropy bytes per month than my current quota provides.** -To increase your quota of entropy bytes you can generate per month, either upgrade from your free account to a paid account or contact Qrypt sales support at support@qrypt.com. +To increase your quota of entropy bytes you can generate per month, contact Qrypt sales support at support@qrypt.com. --- diff --git a/content/getting_started/_index.md b/content/getting_started/_index.md index c5239fb4..4cabcabb 100644 --- a/content/getting_started/_index.md +++ b/content/getting_started/_index.md @@ -1,4 +1,6 @@ +++ +draft = true +# Marking this page as a draft until we fully move to the AWS portal menuTitle = "Getting Started" title = "Getting Started" date = 2021-10-07T11:14:08-04:00 diff --git a/content/openssh/_index.md b/content/openssh/_index.md index dd7b8e0d..81bde6b9 100644 --- a/content/openssh/_index.md +++ b/content/openssh/_index.md @@ -1,4 +1,6 @@ +++ +draft = true +# Marking this page as draft for now because the build of this project requires changes in order to use tokens from the AWS portal instead of the old one menuTitle = "Qrypt OpenSSH" title = "Portable OpenSSH with Qrypt" date = 2021-10-18T08:59:39-04:00 @@ -12,7 +14,7 @@ OpenSSH is a complete implementation of the SSH protocol (version 2) for secure Portable OpenSSH is a port of OpenBSD's OpenSSH to most Unix-like operating systems, including Linux, OS X and Cygwin. It polyfills OpenBSD APIs that are not available elsewhere, adds sshd sandboxing for more operating systems and includes support for OS-native authentication and auditing (e.g. using PAM). The [Qrypt implementation of OpenSSH](https://github.com/QryptInc/openssh-portable) has been modified to provide additional security via the Qrypt Key Generation SDK. -During key exchange (KEX) negotiation, the Qrypt SDK will generate an additional quantum-secure secret to be prepended to the session key hash inputs. Any conventional KEX algorithm can be enhanced by Qrypt security; a Qrypt-secured algorithm can be identified by the ***@qrypt.com*** suffix. +During key exchange (KEX) negotiation, the Qrypt SDK will generate an additional quantum-secure secret to be prepended to the session key hash inputs. Any conventional KEX algorithm can be enhanced by Qrypt security; a Qrypt-secured algorithm can be identified by the **_@qrypt.com_** suffix. Currently availble Qrypt KEX algorithms: @@ -23,15 +25,15 @@ The following sections will cover the two ways of obtaining Qrypt OpenSSH; by ei ## Instructions to create a demo cluster First, visit the [Qrypt portal](https://portal.qrypt.com), make a free account, and generate a keygen token. -Then, download our Docker Compose file [here](/docker-compose.yaml), and paste your token at the location labeled ***\*** +Then, download our Docker Compose file [here](/docker-compose.yaml), and paste your token at the location labeled **_\_** -In your terminal, run `docker-compose up --build` to build both the sshd server and the ssh/sftp client. The terminal will run the ***sshd-server*** container and print its debug outputs. To terminate the cluster, press Ctrl+C. +In your terminal, run `docker-compose up --build` to build both the sshd server and the ssh/sftp client. The terminal will run the **_sshd-server_** container and print its debug outputs. To terminate the cluster, press Ctrl+C. When you're finished with the demo, if you'd like to remove the cluster, run `docker-compose down` and all associated Docker containers and their network will be deleted. ### SSH Demo -In a new terminal, run `docker exec -it ssh-client bash` to open an interactive terminal in the ***ssh-client*** container, which is equipped with both ssh and sftp. +In a new terminal, run `docker exec -it ssh-client bash` to open an interactive terminal in the **_ssh-client_** container, which is equipped with both ssh and sftp. In this container: ```bash @@ -40,9 +42,10 @@ ssh -v -o QryptToken=$TOKEN sshuser@sshd-server.com # Log in to sshd-server.com ``` The default password for sshuser is "pass". -Verbose logging will print a line indicating the KEX algorithm used, and that algorithm's name will end in ***@qrypt.com***, showing that it is Qrypt-modified. +Verbose logging will print a line indicating the KEX algorithm used, and that algorithm's name will end in **_@qrypt.com_**, showing that it is Qrypt-modified. To show that we're now logged into the server: + ```bash bash # Change to a shell that shows the current user, the container name, and the current working directory exit # Exit Bash (when you're done on the server) @@ -51,7 +54,7 @@ exit # Exit sshd-server ### SFTP Demo -Assuming you are still in the ***ssh-client*** container: +Assuming you are still in the **_ssh-client_** container: ```bash echo "0123456789abcdef" > testfile # Create a file to push up to the server @@ -59,9 +62,10 @@ sftp -v -o QryptToken=$TOKEN sshuser@sshd-server.com # Open an sftp session ``` The default password for sshuser is still "pass". -Verbose logging will print a line indicating the KEX algorithm used, and that algorithm's name will end in ***@qrypt.com***, showing that it is Qrypt-modified. +Verbose logging will print a line indicating the KEX algorithm used, and that algorithm's name will end in **_@qrypt.com_**, showing that it is Qrypt-modified. To send a file with sftp: + ```bash cd /sftp/sshuser/upload # Navigate to the user's upload directory ls # Show that the directory is empty @@ -70,6 +74,7 @@ ls # Show that the file is now in the upload directory ``` To verify the test file, open a new terminal and navigate to the file on the server: + ```bash docker exec -it sshd-server bash # Open an interactive terminal the sshd server cd /sftp/sshuser/upload # Navigate to sshuser's upload directory @@ -88,9 +93,10 @@ make clean make make install ``` + To see changes in the server's logging, it must be restarted after the above commands are run in its container. To see changes in the client's on connection logging, you must reconnect after the above commands are run in its container. ## Instructions to build from source -Follow the instructions found in the [README](https://github.com/QryptInc/openssh-portable/blob/master/README.md), under the "Build with QryptSecurityC" header. This requires the Qrypt SDK which can be found [on the Developer Portal](https://portal.qrypt.com/qrypt-sdk). \ No newline at end of file +Follow the instructions found in the [README](https://github.com/QryptInc/openssh-portable/blob/master/README.md), under the "Build with QryptSecurityC" header. This requires the Qrypt SDK which can be found [on the Developer Portal](https://portal.qrypt.com/qrypt-sdk). diff --git a/content/postquantumproxy/_index.md b/content/postquantumproxy/_index.md deleted file mode 100644 index 5e900116..00000000 --- a/content/postquantumproxy/_index.md +++ /dev/null @@ -1,27 +0,0 @@ -+++ -menuTitle = "Post quantum TLS proxy" -title = "Post quantum TLS proxy" -date = 2024-09-24T08:59:39-04:00 -weight = 31 -disableToc = "true" -+++ - -## Overview - -This post quantum TLS proxy combines nginx, oqs OpenSSL, wireguard, and our quantum readiness orchestrator. This can be a stand alone proxy to serve content through traditional nginx configurations. - -### Setup - -There are some exposed environment variables to set the default nginx algorithms. See below. -``` -DEFAULT_GROUPS: x25519:x448:kyber512:p256_kyber512:kyber768:p384_kyber768:kyber1024:p521_kyber1024 -DEFAULT_SIG_ALGS: dilithium3:dilithium5 -DEFAULT_CIPHERS: TLS_CHACHA20_POLY1305_SHA256 -MIN_PROTOCOL: TLSv1.3 -``` - -It also uses a config file at /opt/nginx/example.conf. This config controls the log level and quantum readiness connection. - -A container image is provided and it can be simply run with `docker run -i -t --rm crypto-agility-orchestrator:latest sh` to interact with. - -Please reach out to [Qrypt](https://www.qrypt.com/contact/) for a demo or more information. diff --git a/content/quantumreadiness/_index.md b/content/quantumreadiness/_index.md deleted file mode 100644 index 719d3e24..00000000 --- a/content/quantumreadiness/_index.md +++ /dev/null @@ -1,53 +0,0 @@ -+++ -menuTitle = "Quantum Readiness" -title = "Quantum Readiness with Qrypt" -date = 2024-09-24T08:59:39-04:00 -weight = 30 -disableToc = "true" -+++ - -## Overview - -Quantum Readiness is Qrypt's single pane management console for all Qrypt products. Currently everything is containerized to support a wide range of machines and target environments. - -## General setup - -There are ports to set that allow frontend to backend communication. There are defaults set in the docker-compose.yaml. - -### Local - -There is a provided docker-compose.yaml. Run `docker-compose up -d` to bring up everything. The frontend should be available at http://localhost:8081/. - -### Cloud kubernetes - -Currently this is tested against the Azure cloud. This uses Microsoft Entra ID as the authentication system. WireGuard sidecar container are not covered here, but can be set up for further network security between external connections to this cluster. There will be an example kustomize yaml to follow. Below is a manual setup. - -Create a Microsoft Entra ID to be used as authentication. Note the link, client id, client secret, and redirect url. - -Deploy a postgres database to be used in conjection with the backend. - -Deploy the backend proxy container. The following ports will need to be exposed to other pods 8080, 50051, 50052, 50053. - -Deploy the backend container. Make sure the set the DBCONNSTR environment variable with a connection string to the post res database. - -Deploy the web api container. Make sure to set the BACKEND_API environment variable to the backend proxy and the 50051 port. Set the EXPRESS_LISTEN_PORT environment variable to the port to listen for incoming requests. - -Deploy the auth container. Make sure to set the LOGOUT_REDIRECT_URL to the frontend container's login URI. Set the REDIRECT_URL to the frontend container's auth-redirect URI. Set the EXPRESS_LISTEN_PORT environment variable to the port to listen for incoming requests. Set AUTHORITY environment variable to the Entra ID link. Set CLIENT_ID environment variable to the Entra ID client id. Set the CLIENT_SECRET environment variable to the Entra ID client secret. - -Deploy the frontend container. The default serving port is 5173. Make sure to set the VITE_AUTH_API to the proxy container's 50052 port. Make sure to set the VITE_BACKEND_API to the porxy container's 50053 port. - -The frontend should be available at the hostname set up for the cluster's external IP and the exposed frontend container. This should bring you to a login screen which is hooked up to the Entra ID set up. - -## Post quantum TLS proxy setup - -A WireGuard container is set up to run along side to allow for a symmetric key connection with the use of a preshared key. This will involve a standard WireGuard setup with generating keys and updating the WireGuard configuration to allow a connections. Please see our WireGuard sidecar container as an example. - -To add a post quantum TLS proxy, go through the UI and make sure the add the host name/ip and port that the proxy is set up to listen to GRPC connections. The UI should then show the proxy. - -## On-Prem appliance setup - -The on-prem appliance has to be reachable from the network which quantum readiness is deployed on. To add an on-prem appliance, go to the "on-prem appliance" tab and click "Add an appliance". Make sure to use the correct hostname or IP and port to connect to. - -### Demo - -Please reach out to [Qrypt](https://www.qrypt.com/contact/) for a demo or more information. diff --git a/content/sdk/_index.md b/content/sdk/_index.md index d4f3240b..4fd83b9a 100644 --- a/content/sdk/_index.md +++ b/content/sdk/_index.md @@ -13,7 +13,7 @@ Developers need familiar tools based on modern development practices. We provide The Qrypt SDK includes client library SDKs, cloud-based REST services, command line clients and guidance to help integrate post-quantum security into your applications and services. You can add security features to your applications without being an expert in post-quantum cryptography. -This service requires an access token. Follow the steps in [Getting Started]({{< ref "/getting_started" >}}) to obtain an access token. +This service requires an access token. Please {{< externalLink link="https://www.qrypt.com/contact/" text="contact us" >}} to obtain one. ## [Quickstarts](quickstarts/) @@ -27,7 +27,6 @@ Detailed API References for a growing list of plaforms. Release notes and updates - ## [Nvidia Quantum Secure Gateway](nvidia/) -Qrypt’s BLAST IPsec plug-in documentation \ No newline at end of file +Qrypt’s BLAST IPsec plug-in documentation diff --git a/content/sdk/nvidia/_index.md b/content/sdk/nvidia/_index.md index 0be4a7f3..c5f189f3 100644 --- a/content/sdk/nvidia/_index.md +++ b/content/sdk/nvidia/_index.md @@ -6,7 +6,7 @@ weight = 70 As the quantum era approaches, the need for cryptographic systems that can withstand the power of quantum computing becomes increasingly urgent. Current key exchange mechanisms like Elliptic Curve Diffie-Hellman (ECDH) are vulnerable to attacks from quantum computers, which can easily break these algorithms. To address this looming threat, it is critical to incorporate post-quantum key exchanges alongside traditional methods like (EC)DH to ensure that the resulting shared keys are secure against quantum-based attacks. RFC 9370 provides a framework for enhancing the Internet Key Exchange (IKEv2) protocol by enabling multiple successive key exchanges, including Post-Quantum Cryptography (PQC) techniques. This allows for the seamless integration of quantum-resistant algorithms with existing cryptographic protocols, ensuring compatibility while significantly strengthening security. The derived IKEv2 keys, fortified with these advanced techniques, are thus designed to be robust against the unprecedented capabilities of quantum computers. -Qrypt integrated the BLAST protocol and post-quantum algorithms in IKEv2 as additional key exchange methods, providing security against Harvest Now Decrypt Later (HNDL) attacks and future quantum attacks. This solution, is built as an IPsec plug-in that seamlessly combines existing classical and quantum-secure key exchanges with Qrypt’s BLAST protocol. The solution leverages the [NVIDIA Bluefield-3 DPU’s](https://www.nvidia.com/content/dam/en-zz/Solutions/Data-Center/documents/datasheet-nvidia-bluefield-3-dpu.pdf) hardware capability for secure network communication and optimized performance. Support for the Qrypt plug-in can be easily enabled by configuring the StrongSwan service running on the DPUs. +Qrypt integrated the BLAST protocol and post-quantum algorithms in IKEv2 as additional key exchange methods, providing security against Harvest Now Decrypt Later (HNDL) attacks and future quantum attacks. This solution, is built as an IPsec plug-in that seamlessly combines existing classical and quantum-secure key exchanges with Qrypt’s BLAST protocol. The solution leverages the [NVIDIA Bluefield-3 DPU’s](https://www.nvidia.com/content/dam/en-zz/Solutions/Data-Center/documents/datasheet-nvidia-bluefield-3-dpu.pdf) hardware capability for secure network communication and optimized performance. Support for the Qrypt plug-in can be easily enabled by configuring the StrongSwan service running on the DPUs. --- @@ -37,19 +37,19 @@ There are two primary methods to negotiate additional key exchange algorithms an ### Option 1: Using IKE_INTERMEDIATE Exchanges 1. **IKE_SA_INIT Negotiation**: - - The key exchange method negotiated via Transform Type 4 (ECDH) takes place. - - The initiator includes up to seven newly defined transforms, that represent the extra key exchanges, in the SA payload within the **IKE_SA_INIT** message. - - The responder selects key exchange methods and returns their IDs in the **IKE_SA_INIT** response. - - Additional key exchanges are negotiated, leading to one or more **IKE_INTERMEDIATE** exchanges. + - The key exchange method negotiated via Transform Type 4 (ECDH) takes place. + - The initiator includes up to seven newly defined transforms, that represent the extra key exchanges, in the SA payload within the **IKE_SA_INIT** message. + - The responder selects key exchange methods and returns their IDs in the **IKE_SA_INIT** response. + - Additional key exchanges are negotiated, leading to one or more **IKE_INTERMEDIATE** exchanges. 2. **IKE_INTERMEDIATE Exchanges**: - - For each additional key exchange agreed upon, an **IKE_INTERMEDIATE** exchange is performed. - - The initiator sends key exchange data using the **KEi(n)** payload, protected with current keys **SK_ei/SK_ai**. - - The responder responds with the **KEr(n)** payload, also protected with **SK_er/SK_ar**. - - Both sides compute updated keying materials from the shared secrets generated during these exchanges. + - For each additional key exchange agreed upon, an **IKE_INTERMEDIATE** exchange is performed. + - The initiator sends key exchange data using the **KEi(n)** payload, protected with current keys **SK_ei/SK_ai**. + - The responder responds with the **KEr(n)** payload, also protected with **SK_er/SK_ar**. + - Both sides compute updated keying materials from the shared secrets generated during these exchanges. 3. **IKE_AUTH Exchange**: - - After completing **IKE_INTERMEDIATE** exchanges, the initiator and responder perform the **IKE_AUTH** exchange, as per the IKEv2 specification. + - After completing **IKE_INTERMEDIATE** exchanges, the initiator and responder perform the **IKE_AUTH** exchange, as per the IKEv2 specification. -The shared keying material is completed as follows: +The shared keying material is completed as follows: ``` SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr) @@ -92,39 +92,36 @@ Both the initiator and responder use these updated keys in the next **IKE_INTERM ### Option 2: Using IKE_FOLLOWUP_KE Exchanges 1. **Initial IKE SA Setup**: - - An IKE SA is established using the standard **IKE_SA_INIT** and **IKE_AUTH** exchanges. + - An IKE SA is established using the standard **IKE_SA_INIT** and **IKE_AUTH** exchanges. 2. **CREATE_CHILD_SA Exchange**: - - The ECDH key exchange negotiated via Transform Type 4 takes place in the **CREATE_CHILD_SA** exchange, as per the IKEv2 specification [[RFC7296](https://datatracker.ietf.org/doc/html/rfc7296)]. - - The initiator proposes additional key exchanges via ADDKE(Additional Key Exchange) Transform Types in the **CREATE_CHILD_SA** payload. - - If the responder agrees, additional key exchanges occur in a series of **IKE_FOLLOWUP_KE** exchanges. + - The ECDH key exchange negotiated via Transform Type 4 takes place in the **CREATE_CHILD_SA** exchange, as per the IKEv2 specification [[RFC7296](https://datatracker.ietf.org/doc/html/rfc7296)]. + - The initiator proposes additional key exchanges via ADDKE(Additional Key Exchange) Transform Types in the **CREATE_CHILD_SA** payload. + - If the responder agrees, additional key exchanges occur in a series of **IKE_FOLLOWUP_KE** exchanges. 3. **IKE_FOLLOWUP_KE Exchanges**: - - Similar to the first option, but here additional key exchanges occur directly after the **CREATE_CHILD_SA** exchange. - - Cryptographic parameters for ADDKE are exchanged. The exchange is protected with keys established through the **CREATE_CHILD_SA** exchange. - + - Similar to the first option, but here additional key exchanges occur directly after the **CREATE_CHILD_SA** exchange. + - Cryptographic parameters for ADDKE are exchanged. The exchange is protected with keys established through the **CREATE_CHILD_SA** exchange. After the exchanges, both peers compute updated keying materials as follows: - + For IKE SA rekey: ``` SKEYSEED = prf(SK_d, SK(0) | Ni | Nr | SK(1) | ... | SK(n)) - + ``` - + - **SK_d** is from the existing IKE SA. - **SK(0)**, **Ni**, and **Nr** are the shared key and nonces from the CREATE_CHILD_SA exchange. - **SK(1)...SK(n)** are shared keys from additional key exchanges. For Child SA creation or rekey: - + ``` KEYMAT = prf+ (SK_d, SK(0) | Ni | Nr | SK(1) | ... | SK(n)) - + ``` - - + In both cases, **SK_d** comes from the existing IKE SA, and the keying material is derived from **SK(0), Ni, Nr**, and additional shared keys. - ``` [Initiator] [Responder] @@ -149,17 +146,17 @@ In both cases, **SK_d** comes from the existing IKE SA, and the keying material ## Choosing the Method -The choice between using **IKE_INTERMEDIATE** or **IKE_FOLLOWUP_KE** exchanges depends on the peers’ security policies. If the initial Child SA must be quantum secure, negotiating additional key exchanges through **IKE_INTERMEDIATE** exchanges may be preferable. +The choice between using **IKE_INTERMEDIATE** or **IKE_FOLLOWUP_KE** exchanges depends on the peers’ security policies. If the initial Child SA must be quantum secure, negotiating additional key exchanges through **IKE_INTERMEDIATE** exchanges may be preferable. --- # BLAST Integration in IKEv2 -Qrypt solution leverages [RFC9370](https://datatracker.ietf.org/doc/rfc9370/) specification that describes a method to perform multiple successive key exchanges in IKEv2. Qrypt keys are generated independently on each endpoint, however, to establish the same set of keys, parties must exchange the associated key metadata. Additional IKEv2 key exchanges are used to exchange the metadata. +Qrypt solution leverages [RFC9370](https://datatracker.ietf.org/doc/rfc9370/) specification that describes a method to perform multiple successive key exchanges in IKEv2. Qrypt keys are generated independently on each endpoint, however, to establish the same set of keys, parties must exchange the associated key metadata. Additional IKEv2 key exchanges are used to exchange the metadata. ## The BLAST Protocol -BLAST is the protocol used to eliminate key transmission and safeguard data against the Harvest Now Decrypt Later (HNDL) attack.  +BLAST is the protocol used to eliminate key transmission and safeguard data against the Harvest Now Decrypt Later (HNDL) attack. 1. The BLAST architecture enables generation of identical keys at multiple endpoints, so they are never distributed. 2. Caches of random allow for sampling by multiple clients – with time and usage controls that trigger cache shredding. @@ -200,14 +197,13 @@ For more information see [BLAST](https://cs.nyu.edu/~dodis/ps/blast.pdf) {{< figure src="images/Diagram_1.png" >}} - --- # NVIDIA Quantum Secure Gateway Architecture {{< figure src="images/Diagram_4.png" >}} -The process starts with IKEv2 negotiating Security Associations (SAs) between the initiator and responder, defining cryptographic parameters like algorithms and key lengths. An SA is uniquely identified by a triplet, which consists of the security parameter index (SPI), destination IP address, and security protocol identifier. An SPI is a 32-bit number. It is transmitted in the AH/ESP header. In IPsec, ESP uses these SAs to secure IP packets by referencing the Security Parameter Index (SPI) to identify the correct SA for each packet. +The process starts with IKEv2 negotiating Security Associations (SAs) between the initiator and responder, defining cryptographic parameters like algorithms and key lengths. An SA is uniquely identified by a triplet, which consists of the security parameter index (SPI), destination IP address, and security protocol identifier. An SPI is a 32-bit number. It is transmitted in the AH/ESP header. In IPsec, ESP uses these SAs to secure IP packets by referencing the Security Parameter Index (SPI) to identify the correct SA for each packet. ### Association of ESP with Security Associations (SAs) @@ -221,11 +217,11 @@ The process starts with IKEv2 negotiating Security Associations (SAs) between th 2. **SA Lookup**: Using the SPI, ESP searches its Security Association Database (SAD) to find the corresponding SA that matches the SPI. The SAD contains entries for each active SA, indexed by their SPIs. -3. **Applying Security Parameters**: Once the matching SA is identified, ESP retrieves the cryptographic parameters (such as encryption and authentication algorithms) associated with that SA. It then processes the packet accordingly to ensure data confidentiality and integrity. +3. **Applying Security Parameters**: Once the matching SA is identified, ESP retrieves the cryptographic parameters (such as encryption and authentication algorithms) associated with that SA. It then processes the packet accordingly to ensure data confidentiality and integrity. ### **Open vSwitch (OVS)** -OVS is used to facilitate the transfer of plaintext messages between the host and the DPU. In this context, OVS acts as a software-based network switch that manages network traffic, routing messages between the host’s CPU and the DPU without encryption. +OVS is used to facilitate the transfer of plaintext messages between the host and the DPU. In this context, OVS acts as a software-based network switch that manages network traffic, routing messages between the host’s CPU and the DPU without encryption. --- @@ -234,9 +230,9 @@ OVS is used to facilitate the transfer of plaintext messages between the host an To set up east-west overlay encryption, first ensure that the strongSwan is built on the target machine. Next, complete the following two steps: 1. **Configure the OVS (Open vSwitch):** - - Setup the OVS bridge + - Setup the OVS bridge - Configure the authentication method -2. **Run the script:** Execute the following command, which runs the *ovs-monitor-ipsec* script and automates the configuration process: +2. **Run the script:** Execute the following command, which runs the _ovs-monitor-ipsec_ script and automates the configuration process: ```bash systemctl start openvswitch-ipsec.service @@ -247,46 +243,47 @@ To set up east-west overlay encryption, first ensure that the strongSwan is buil ### **Set up OVS bridges in both hosts** - Start Open vSwitch. If your operating system is Ubuntu, run the following on both *Arm_1* and *Arm_2*: - - ```bash - service openvswitch-switch start - ``` + + ```bash + service openvswitch-switch start + ``` - Start OVS IPsec service. Run the following on both *Arm_1* and *Arm_2*: - - ```bash - systemctl start openvswitch-ipsec.service - ``` - + ```bash + systemctl start openvswitch-ipsec.service + ``` - Before you can set up OVS bridges in both DPUs, and add the physical function (PF) or its associated representor (PF_REP) to a new bridge, they must be detached from any existing OVS bridge they are associated with. - - Detach PF_REP and PF from their current bridge: - ```bash - sudo ovs-vsctl del-port ovsbr1 $PF_REP - sudo ovs-vsctl del-port ovsbr1 $PF - - ``` - Note that “ovsbr1” is a sample name given in these instructions; the name on your system could be different. - - Next, run the following on both Arm_1 and Arm_2: - ```bash - sudo ovs-vsctl add-br my-ovs-br - sudo ovs-vsctl add-port my-ovs-br $PF_REP - sudo ovs-vsctl add-port my-ovs-br $PF - sudo ovs-vsctl set Open_vSwitch . other_config:hw-offload=true - ``` - - If your operating system is CentOS, run the following on both *Arm_1* and *Arm_2*: - - ```bash - service openvswitch restart - ``` + + Detach PF_REP and PF from their current bridge: + + ```bash + sudo ovs-vsctl del-port ovsbr1 $PF_REP + sudo ovs-vsctl del-port ovsbr1 $PF + + ``` + + Note that “ovsbr1” is a sample name given in these instructions; the name on your system could be different. + + Next, run the following on both Arm_1 and Arm_2: + + ```bash + sudo ovs-vsctl add-br my-ovs-br + sudo ovs-vsctl add-port my-ovs-br $PF_REP + sudo ovs-vsctl add-port my-ovs-br $PF + sudo ovs-vsctl set Open_vSwitch . other_config:hw-offload=true + ``` + + If your operating system is CentOS, run the following on both *Arm_1* and *Arm_2*: + + ```bash + service openvswitch restart + ``` - Set up IPsec tunnel on the OVS bridge. Three authentication methods are possible. Select your preferred method and follow the steps relevant to it. Note that some authentication methods require you to create certificates (self-signed or certificate authority certificates). ### Authentication Methods -There are three authentication methods: +There are three authentication methods: **Using pre-shared key** @@ -299,7 +296,7 @@ ovs-vsctl add-port vxlan-br tun -- \ options:remote_ip=$ip2 \ options:key=100 \ options:dst_port=4789 \ - options:psk= your pre-shared secret value + options:psk= your pre-shared secret value ``` On *Arm_2*, run: @@ -313,29 +310,32 @@ sudo ovs-vsctl add-port vxlan-br tun -- \ options:dst_port=4789\ options:psk=your pre-shared secret value ``` + {{% notice note %}} Pre-shared key (PSK) based authentication is easy to set up but less secure compared with other authentication methods. You should use it cautiously in production systems. {{% /notice %}} -**Using self-signed certificates** +**Using self-signed certificates** -Generate self-signed certificate in both *Arm_1*and *Arm_2*. Then copy the certificate of *Arm_1* to *Arm_2* and the certificate of *Arm_2* to *Arm_1*. +Generate self-signed certificate in both *Arm_1*and *Arm_2*. Then copy the certificate of *Arm_1* to *Arm_2* and the certificate of *Arm_2* to *Arm_1*. -On *Arm_1*, run: +On _Arm_1_, run: Generate self-signed certificates + ```bash -sudo ovs-pki req -u host_1. +sudo ovs-pki req -u host_1. sudo ovs-pki self-sign host_1 sudo ovs-vsctl set Open_vSwitch . other_config:certificate=/etc/swanctl/x509/host_1-cert.pem \ other_config:private_key=/etc/swanctl/private/host_1-privkey.pem ``` -On *Arm_2*, run: +On _Arm_2_, run: Generate self-signed certificates + ```bash -sudo ovs-pki req -u host_2. +sudo ovs-pki req -u host_2. sudo ovs-pki self-sign host_2 sudo ovs-vsctl set Open_vSwitch . other_config:certificate=/etc/swanctl/x509/host_2-cert.pem \ other_config:private_key=/etc/swanctl/private/host_2-privkey.pem @@ -347,9 +347,9 @@ sudo ovs-vsctl set Open_vSwitch . other_config:certificate=/etc/swanctl/x509/hos **Using CA-signed certificate:** -First you need to establish a public key infrastructure (PKI), generate certificate requests, and copy the certificate request of *Arm_1* to *Arm_2* and *Arm_2* to *Arm_1* . Sign the certificate requests with the CA key. +First you need to establish a public key infrastructure (PKI), generate certificate requests, and copy the certificate request of *Arm_1* to *Arm_2* and _Arm_2_ to _Arm_1_ . Sign the certificate requests with the CA key. -On *Arm_1*, run: +On _Arm_1_, run: ```bash sudo ovs-pki init --force @@ -358,9 +358,10 @@ cd /certsworkspace sudo ovs-pki req -u host_1 sudo ovs-pki sign host1 switch  ``` + After running this code, you should have host_1-cert.pem, host_1-privkey.pem, and cacert.pm in the certsworkspace folder. -On *Arm_2,* run: +On _Arm_2,_ run: ```bash sudo ovs-pki init --force @@ -369,6 +370,7 @@ cd /certsworkspace sudo ovs-pki req -u host_2 sudo ovs-pki sign host_2 switch ``` + After running this code, you should have host_2-cert.pem, host_2-privkey.pem, and cacert.pm in the certsworkspace folder. - Copy the certificate of *Arm_1* to *Arm_2* and the certificate of *Arm_2* to *Arm_1*. @@ -376,9 +378,9 @@ After running this code, you should have host_2-cert.pem, host_2-privkey.pem, a - On each machine, move the local private key (*host_1-privkey.pem* if on *Arm_1* and *host_2-privkey.pem* if on *Arm_2*) to */etc/swanctl/private* if on Ubuntu, or */etc/strongswan/swanctl/private* if on CentOS. - On each machine, copy *cacert.pem* to the *x509ca* directory under */etc/swanctl/x509ca/* if on Ubuntu, or */etc/strongswan/swanctl/x509ca/* if on CentOS. -Configure IPsec tunnel to use CA-signed certificate: +Configure IPsec tunnel to use CA-signed certificate: -On *Arm_1*, run: +On _Arm_1_, run: ```bash sudo ovs-vsctl set Open_vSwitch . \ @@ -387,7 +389,7 @@ On *Arm_1*, run: other_config:ca_cert=/etc/strongswan/swanctl/x509ca/cacert.pem ``` -On *Arm_2*, run: +On _Arm_2_, run: ```bash sudo ovs-vsctl set Open_vSwitch . \ @@ -400,23 +402,23 @@ On *Arm_2*, run: Ensure that the strongSwan has already been built on your system. -After OVS is configured, run the following command: +After OVS is configured, run the following command: ```bash systemctl start openvswitch-ipsec.service ``` -This command automatically runs the *ovs-monitor-ipsec* script and generates the *swanctl.conf* file. This command also runs the strongSwan IPsec service. +This command automatically runs the _ovs-monitor-ipsec_ script and generates the _swanctl.conf_ file. This command also runs the strongSwan IPsec service. ### Script Parameters -Note that critical information such as key exchange and authentication algorithms to be used for IKE SA and ESP SA are passed in the *ovs-monitor-ipsec* script to later generate a *swanctl.conf* file. Ensure that the script contains all the key exchange algorithms to be used for IKE SA establishment. For instance, parameters *ke1_kyber3-ke2_blast* passed in the *ovs-monitor-ipsec* script +Note that critical information such as key exchange and authentication algorithms to be used for IKE SA and ESP SA are passed in the _ovs-monitor-ipsec_ script to later generate a _swanctl.conf_ file. Ensure that the script contains all the key exchange algorithms to be used for IKE SA establishment. For instance, parameters _ke1_kyber3-ke2_blast_ passed in the _ovs-monitor-ipsec_ script ```bash sudo sed -i 's/aes256gcm16-modp2048-esn/aes256gcm16-modp2048-ke1_kyber3-ke2_blast-esn/g' /usr/share/openvswitch/scripts/ovs-monitor-ipsec ``` -will result in *swanctl.conf* parameters: +will result in _swanctl.conf_ parameters: ``` esp_proposals = aes128gcm128-x25519-ke1_kyber3-ke2_blast @@ -424,7 +426,7 @@ esp_proposals = aes128gcm128-x25519-ke1_kyber3-ke2_blast ### strongSwan configuration file -Here’s a basic structure for the *swanctl.conf* file that includes necessary parameters for both ends of the connection (referred to as Left (BFL) and Right (BFR)): +Here’s a basic structure for the _swanctl.conf_ file that includes necessary parameters for both ends of the connection (referred to as Left (BFL) and Right (BFR)): ``` conn-defaults { @@ -434,19 +436,19 @@ conn-defaults { mobike = no proposals = aes128-sha256-x25519 } - + child-defaults { esp_proposals = aes256gcm16-modp2048-ke1_kyber3-ke2_blast-esn mode = transport policies_fwd_out = yes start_action = start } - + connections { tun-1 : conn-defaults{ local_addrs = 0.0.0.0/0 remote_addrs = 192.168.50.2 - + local { auth = psk id = 192.168.50.1 @@ -455,7 +457,7 @@ connections { auth = psk id = 192.168.50.2 } - + children { tun-in-1 : child-defaults { local_ts = 192.168.50.1/32 [udp/4789] @@ -470,7 +472,7 @@ connections { } } } - + secrets { ike-tun { id = 192.168.50.1 @@ -480,6 +482,7 @@ secrets { ``` If using pre-shared key (PSK) for authentication, add a section to the swanctl.conf file: + ``` secrets { ike-BF { @@ -490,15 +493,13 @@ ike-BF { } ``` -Ensure that all the data needed to generate the *swanctl.conf* file is correctly passed in the *ovs-monitor-ipsec* script. +Ensure that all the data needed to generate the _swanctl.conf_ file is correctly passed in the _ovs-monitor-ipsec_ script. For more information see [ NVIDIA DOCA East-West Overlay Encryption Application](https://docs.nvidia.com/doca/sdk/nvidia+doca+east-west+overlay+encryption+application/index.html) - --- - -# Build strongSwan with liboqs and Qrypt's BLAST plugin +# Build strongSwan with liboqs and Qrypt's BLAST plugin Ensure that cmake is installed before completing the steps below. @@ -538,9 +539,9 @@ git checkout BF-6.0.0beta4-qrypt-plugins ### Edit the plugin conf files -Create a free account at https://docs.qrypt.com/getting_started/ This will enable you to generate JSON web tokens (JWT) that you'll need to add to the conf files. +PLease contact us to obtain the JSON web token (JWT) that you'll need to add to the conf files. -*strongswan/src/libstrongswan/plugins/quantum_entropy/quantum-entropy.conf*: +_strongswan/src/libstrongswan/plugins/quantum_entropy/quantum-entropy.conf_: ``` quantum_entropy { @@ -560,7 +561,7 @@ quantum_entropy { ``` -*strongswan/src/libstrongswan/plugins/blast/blast.conf:* +_strongswan/src/libstrongswan/plugins/blast/blast.conf:_ ``` blast { @@ -599,4 +600,4 @@ sudo systemctl stop strongswan.service sudo systemctl start strongswan.service sudo systemctl status strongswan.service -``` \ No newline at end of file +``` diff --git a/content/sdk/quickstarts/cpp/_index.md b/content/sdk/quickstarts/cpp/_index.md index d33110f9..696996a0 100644 --- a/content/sdk/quickstarts/cpp/_index.md +++ b/content/sdk/quickstarts/cpp/_index.md @@ -12,8 +12,8 @@ Currently we provide Distributed Key Generation. The latest Qrypt SDK is built using the following compilers. -| Platform | Version | Compiler | CPU | -| -------- | ------- | --------- | --- | +| Platform | Version | Compiler | CPU | +| -------- | ------- | ---------- | --- | | Ubuntu | 22.04 | gcc 11.4.0 | x64 | --- @@ -24,12 +24,6 @@ Find the finalized code for these quickstarts on {{< externalLink link="https:// --- -## Prerequisites - -A Qrypt Account. {{< externalLink link="https://portal.qrypt.com/register" text="Create an account for free" >}}. - ---- - ## Quickstarts ### {{< externalLink link="https://github.com/QryptInc/qrypt-security-quickstarts-cpp" text="Distributed key generation" >}} diff --git a/docs/404.html b/docs/404.html index accdac81..e3446a9f 100644 --- a/docs/404.html +++ b/docs/404.html @@ -1,7 +1,7 @@ - + @@ -9,15 +9,15 @@ 404 Page not found - - - - - - - + + + + + + + - +