FAQ

The widespread adoption of machine learning (ML) algorithms is hindered by the reluctance or inability of data owners to share their data with ML developers due to potential threats such as data leaks, theft, and misuse. Data privacy in AI will be a key issue in the coming decade.

Data owners and ML teams training models on sensitive data, as well as cloud service providers and participants in multi-party computations.

Confidential, personal, and other information (intellectual property, know-how, secret field data) used in training machine learning models, including the model itself as a result of intellectual labor.

We employ a combination of one secure computation technique and two privacy-preserving protocols to safeguard sensitive data throughout the machine learning process.

Secure Computation Technique:
• Functional Transformation

Privacy-Preserving Protocols:
• Federated Learning
• Secure Multi-Party Computation

The level of protection varies depending on the chosen approach. The minimum protection covers data transmission, model training, and model quality evaluation. The maximum protection encompasses data transmission, storage, model training, model quality evaluation, and result retrieval.

Our product supports a wide range of data formats, including text, numbers, tables, time series, images, audio, video, and geolocation data.

Our product seamlessly integrates with various ML architectures, including logistic regression, decision trees, neural networks, and generalized linear models.

The computational effort required to crack our security measures far exceeds the estimated lifespan of the universe, rendering them virtually impenetrable.

We offer a range of privacy-enhancing approaches with varying trade-offs between performance and security. Some methods preserve model performance and training time but return the model results in the open, while others may impact training and inference time but maintain result confidentiality.

The choice of approach depends on the client's specific requirements. Testing all solutions on open datasets and standard network architectures provides limited insights, as the performance will inevitably vary based on the client's model architecture, desired security level, input data characteristics, and other factors.

Data preparation (collection and labeling) is the responsibility of the data owner seeking to implement an ML solution. Our focus lies in ensuring the security of sensitive data during transmission to external computing resources or third parties.

Dataset size plays a significant but not decisive role.

When evaluating competitors, it's crucial to compare specific companies and their offerings. To make an informed decision, consider the following questions:

a) Practical Value vs. Theoretical Research:
Do the company's solutions address real-world problems or are they primarily focused on theoretical research?

b) Media Content Processing Efficiency:
Can the company's products handle media content without compromising processing time or increasing data volume?

c) Adaptability and Applicability:
How easily can the company's solutions be adapted for practical applications and real-world neural network modeling? Are they compatible with a wide range of neural network architectures?

d) Open-Source Licensing:
If the company claims to offer open-source solutions, does the licensing truly allow for commercial use?

e) Diversity of Methods and Protocols:
Does the company employ a variety of methods and protocols, or does it rely on a single approach for all cases? Do they adhere to principles of flexibility, effective combination, and avoiding redundancy?

f) Suitability of Data Protection:
Is the company's data protection approach tailored for machine learning? Does it involve actual encryption or merely data substitution within documents? Is it simply additional traffic encryption, with data decrypted before machine learning? Or are encrypted data completely excluded from model training?

Comprehensive comparative analysis can only be conducted after addressing all these questions.

Hashing is a technique for anonymizing personal data in text information. However, hashed data cannot be directly used in machine learning and serves only as a linking entity. Our product, in contrast, protects sensitive data that is actively utilized in machine learning processes.

Classic hashing involves applying a cryptographic hash function to arbitrary data, generating a fixed-length hash value. This transformation is irreversible, akin to passing data through a meat grinder. Currently, there are no known approaches to leverage hashing in machine learning. It does not have the properties we need, unlike our proposed defense methods.

Our data protection methods are designed to function effectively even without relying on Trusted Execution Environments (TEEs).

Additional encryption between the customer and the data processor is crucial in scenarios where:

• The customer is unwilling or unable to share data openly, especially when dealing with sensitive personal information such as facial images, passport scans, or medical records.
• The data processor, as the developer, has concerns about transmitting data to external computing environments (cloud services) due to potential data leakage risks.

Data breaches can occur during processing, not just during storage. Relying solely on storage restrictions is insufficient for data protection.

Fully Homomorphic Encryption (FHE) is applicable to neural networks and other machine learning algorithms that can be represented as a composition of polynomial functions. For instance, neural networks composed of convolutional layers, fully connected layers, average pooling layers, and polynomial activation functions (or activation functions that can be approximated by polynomials) can be used in conjunction with FHE. Logistic regression and Fisher's linear discriminant analysis are examples of other machine learning algorithms that can be applied in combination with FHE. We also see potential in the synergy between FHE and the recently proposed neural network architecture called KAN, where splines―piecewise polynomial functions defined by different polynomials over different intervals―form the basis of the network.

Federated Learning (FL) enables collaborative training of a neural network (NN) by multiple data owners. Each data owner trains the shared NN architecture on their own trusted resources using their private data, and they interactively exchange auxiliary information with a publicly accessible resource to construct a unified NN model.

Secure Multi-Party Computation (SMPC) is a specialized protocol for collaboration among multiple parties to jointly train an ML algorithm using data owned by multiple parties. In this protocol, parties exchange information derived from their data, which does not reveal the original data itself but allows for training the ML algorithm. Training can be conducted on the resources of one or more (possibly all) participating parties or on external resources not owned by any party.

The approach for using protected and plaintext data together depends on the specific solution used:
• Veils-based Approach: if our Veils approach is employed, models trained on Veils-protected data can be applied to unencrypted data if the same Veils transformation is pre-applied to the unencrypted data.
• FHE-based Approach: for other approaches, particularly when an existing solution for unencrypted data needs to be adapted for encrypted data, Fully Homomorphic Encryption (FHE) can be utilized.
• Separate Model Training and Aggregation: alternatively, separate models can be trained for encrypted and unencrypted data, and their outputs can be aggregated in a suitable manner.
Direct integration of encrypted data into unencrypted data is not feasible due to the fundamental differences in their numerical representation domains.

Our software enables the creation of different security levels for different confidential data.

The speed of encryption by algorithms that have homomorphism is indeed lower than commonly known encryption algorithms. But it is the performance of operations on the encrypted data that contributes the most. Therefore, the speed can be acceptable if the complexity of the required operations is low.

This is a pressing constraint; those functions that cannot be represented as a composition of valid operations or acceptably approximated by them are not supported.

Generating synthetic data appears to be the most promising approach for protecting original data while preserving its structure and ranking.

When using our Veils-based solution, both 1000 passports and 10,000 passports, or any number of passports, will be protected.

If data scientists are using non-secure data now and plan to switch to secured data, then in any case the existing pipeline is modified. Slightly different grids, ways to pre and post process the data. This is compensation for the additional feature, but all these changes do not dramatically change the look of the work.

No, we only provide a product that helps protect the data. You can use this data in ML and DS on your own afterwards.

Yes, synthetic data is generated to ensure that the trained model performs well on real data.

We proactively monitor and apply classic and innovative vulnerability scanning techniques.

We are engaged in the development of data protection methods that can work independently of access rights differentiation systems.

Here we can talk about two options:

1. Providing the data scientist with a sample of real data to get acquainted with and evaluate the properties in order to analyze it and use it to tune weights, logic, features, stuff like that.

2. Providing the data scientist with synthetically generated data that reproduces the statistical properties of the original data.

If the data scientist is a representative of the data owner, the data scientist works with open data.
If the data scientist is a representative of a third-party organization without the right to access the original data, our product will not allow the data scientist to view the data.

We are doing research on supporting self-learning LLMs.

In the case of closed-architecture LLMs, there is no way to quantize for homomorphic inference, nor to retrain in order to fuse with Veils.

No, our product is designed to be user-friendly and accessible to individuals with varying levels of technical expertise, including those without a technical background.

Yes, in this case the owner's data can be used in a secure form to train an ML algorithm for a third party, who will then use the algorithm.

The data is transformed in a special way so that it cannot be recovered, identified, and/or interpreted and still be usable in the training of ML algorithms.

Fully homomorphic encryption (FHE) algorithms allow performing addition and multiplication operations on ciphertexts such that the sum and product of ciphertexts after decryption is equal to the sum and product of the corresponding public data.

The Functional Transformation (Veils) approach protects the trained model as well.

Comparing our solutions and blockchain is not meaningful because blockchain technology is designed to ensure data integrity and has nothing to do with ensuring data privacy and training ML algorithms.

Absolutely not! The point of the solution is to ensure that no one else has access to the data except the data owner.

The point of the solution is to ensure that no one else has access to the data except the data owner.