Once a message is created, it must be encrypted. XQ’s process begins with retrieving quantum entropy from the XQ quantum server to either be used as the secret key for the encryption or as a seed for generating a new key pair. After the quantum entropy is received, the encryption is configured using a selected cryptographic library, such as OpenSSL. Next, the user is validated via the subscription server, returning a pre-auth token. The account is either confirmed via confirmation email or via API call with associated PIN from email and pre-auth token. Once the account is activated, the pre-auth token is submitted to the subscription server to receive an access token. The key is then submitted to the server with the access token and the recipient address. An encrypted packet is received which is then submitted along with the same access token to the validation server. The packet is verified and a locator token is returned, which will be used by the recipient to request the key.

Decryption: 

1. Client receives encrypted message and the token
2. Client makes request to XQ backend and passes access token and the token extracted from the message
3. Backend checks that access token received is valid and checks that the user who sent the token is a valid user and allowed to view the message
4. After user is validated as a recipient, backend sends encryption key to that client
5. Client uses encryption key to decrypt the data. 

XQ key generation and distribution system operate outside the security of a mobile or cloud app. XQ only handles policy-based key distribution (never the data). Moreover, regulated enterprises have the option of running XQ’s software in their own AWS account or server.  

Another important aspect of XQ is that edge based processing model enables every transaction to have a different key.  When combined with XQ’s out-of-band key distribution, application developers and enterprises benefit from a level of data protection that is unparalleled in Internet-scale systems.

Zscalar is a managed vpn to compete with cisco. Though virtual, it is controlling and connecting access to the network, not protecting data at the data access level.

XQ uses zero-trust to protect the data itself, not the network access as in the case of Zscalar. XQ additionally provides management of content only readable by people/apps/endpoints who are supposed to read it. The content itself is encrypted in a distributed data approach whereas Zscalar is not aware of who or how data is accessed after it arrives at the end destination. 

Zscalar and XQ can work as complements to each other.

ANSWER: The API keys are a requirement on our public instance ( and are pretty standard when dealing with 3rd party integrations ), but can be made optional on enterprise deployments by changing the server configuration. However, you will lose a level of traceability since aside from scoping, the API keys are used for identifying the application that is making that call.

XQ is different than standard envelope encryption as it uses a Zero Trust security model. For example with AWS envelope encryption users need to “trust” AWS to storing their master key. In contrast with XQ users can have Zero Trust in AWS as they have their own key distribution server which they can operate in AWS, Azure or even a physical server. 

While XQ seems similar to existing HSM or KMS based key management solutions it is optimized for scale and simplicity while utilizing a true Zero Trust Architecture. With XQ, edge based key distribution “distributes” the computational load while the ability to deploy an array of XQ Key Caches ensures scale and no single point of failure. When combined with a ZTA based identity-based authorization model, XQ is far more elegant for Smart Energy and Transportation systems. 

The XQ Key Cache is a fully self-contained key distribution and logging solution but can be combined with HMS/KMS solutions for hybrid solutions. XQ can be used to support frontend IoT sensors and data lakes while KMS would be used only for long term archiving of keys. Thus the use of KMS and cost would be reduced.

XQ generates quantum-safe keys that are virtually impossible to crack via brute force attacks while also providing the capability to manage encryption keys via a secure tokenization process. 

XQ does not require current technology stacks to be uprooted and replaced, but instead is categorized as a Quantum-Safe Encryption as a Service (QEaaS) solution that is layered on top of existing security controls to enhance security via stronger encryption and secure key management. Users and applications can encrypt data on edge devices either via XQ’s applications or via use of XQ’s APIs and SDKs.

Only users who are valid recipients of the message can receive the decryption keys. As a result, a user who is not a valid recipient of the message will not be able to retrieve keys, even in the event that the user possesses an XQ token from within the message. The user may have the token, but will not be able to get the encryption key off the server due to the token validation. Therefore, encryption keys are only retrievable by valid recipients of the message. 

XQ also provides the capability of message tracking and revocation. All messages are tracked by their status, as well as IP address of accessing recipient. If a message is sent accidentally or the recipient is deemed not longer valid, the sender can revoke the message. In the event that the recipient uses the token to try to retrieve the encryption key, it will not be possible due to the message previously being revoked.

XQ has developed a new data protection concept that combines the best features of file encryption and VPNs into one service.  With XQ, data is encrypted at the edge device (phone, PC, IoT Gateway) and then routed to one or more destinations.  The encrypted data is wrapped in a meta-tag which serves as a pointer to the policies set by the data owner.  The policies and keys for access and authorization is sent to a key cache. 

The XQ backend cache only forwards keys and never touches the data nor knows anything about the edge devices except identity and authorization unless explicitly added to the metadata. All events are automatically logged and geo-tagged to meet compliance requirements as well as instantly detecting data exfiltration attempts. To meet emerging privacy laws such as CCPA and GDPR,  XQ provides the option to regulated entities of running their own key cache on a cloud or physical server.