Frequently Asked Questions
What is application-level security?
Application-level security is a data security solution that protects data as soon as it is created in an application. In data security, the application is the top layer where users directly input data and information before sending it anywhere. When you secure data here, it is protected from the moment of creation instead of after it has already been in transit.
How are application level and operating system level security different?
The difference between application level and operating system level security is where the data is actually being secured. The application level is where data is created/inputted by users. When data is secured here, it is secured the moment that it is created, protecting the data from end to end. On the other hand, operating system level security refers to when data leaves the application, travels to the operating system, and is then secured by something like TLS security.
What is FIPS 140-3 and why is it important?
FIPS stands for Federal Information Processing Standard Publication. It is required for most regulated environments and our MTE technology is validated through a NIST-approved third-party laboratory for FIPS 140-3.
FIPS 140-3 is regulated as the best practices and standards for cryptographic algorithms by the National Institute of Standards and Technology. FIPS 140-3 is aligned better with international standards to provide an updated and more stringent standard for security modules.
What is the difference between FIPS 140-3 validated vs. certified?
The difference between being FIPS 140-3 validated and certified is that validated means that the algorithms have been tested by a third-party NIST-approved laboratory while certified means that NIST has reviewed the validation and gave their stamp of approval. A technology must be validated before it is certified and the time between becoming certified is determined by how long it takes for NIST to have time to review.
How does MTE technology secure mobile applications?
MTE Technology secures mobile applications through its MTE Mobile Toolkit. This toolkit is configurable on each endpoint and session, uniquely protecting each data payload. MTE can detect when there is a threat to the mobile device or application’s data and respond by intentionally corrupting the synchronization making the data unusable to bad actors. By securing data from application to server-side application, MTE Mobile addresses vulnerabilities such as jailbroken or rooted devices, SIM swap attacks, and application-based threats (malware, spyware, privacy threats, vulnerable applications).
What kinds of threats does MTE technology protect against?
MTE protects against threats such as man-in-the-middle attacks- including injection, replay and delay, inspection, spoofing and eavesdropping- and OS (operating system) attacks including heighten privilege and memory reading.
How does MTE protect against zero-days?
MTE protects against zero-days by always providing full end-to-end protection of data. Zero-day attacks happen when hackers find ways to unexpectedly steal data, leaving companies to retroactively attempt to implement stronger security. MTE uses zero-trust with full knowledge to eliminate the risks that leave systems vulnerable to those attacks and to ensure that the data will be fully secured from any actions bad actors may take.
Why use MTE technology if I am already using TLS?
While TLS has been considered a standard in the data security world, it has many known vulnerabilities that bad actors continue to exploit:
- TLS is only point to point and cannot secure data from end-to-end without un-securing and re-securing the data at each hop
- TLS is an all-or-nothing approach. MTE can be applied to specific pieces of data within a transmission and does not encapsulate the whole transmission. This allows data to remain secure through multiple hops and different pieces of data to be accessible by different endpoints
- TLS is session-based with a handshake required. MTE is Transmission based with the ability to persist state between sessions eliminating handshakes.
- TLS is zero-knowledge, MTE can be full-knowledge.
- You don’t control TLS and are putting a lot of trust in it to make sure your data isn’t exposed
- TLS requires separate monitoring and updates that include patching. When TLS vulnerabilities are discovered, security bulletins are posted with required and regular maintenance
- MTE secures data before TLS is used
Does MTE use AES Encryption?
No, MTE does not use AES Encryption. Instead, it uses AES and SHA based DRBGs to create random streams of values to replace sensitive data.
How do you secure large pieces of data?
With our Eclypses MKE (Managed Key Encryption), which uses AES encryption to encrypt data with a key randomly generated by MTE.
What is the Eclypses Cryptographic Library (ECL)?
The Eclypses Cryptographic Library (ECL) houses all cryptographic algorithms used by MTE and all MTE add-ons. ECL is what carries the FIPS 140-3 validation and is a way of separating what NIST considers a cryptographic algorithm from the other functions of MTE.
What is the implementation process for MTE technology?
The implementation process for MTE Technology can be completed in only a matter of days. To aid in an easy implementation, we have ample resources available for reference including:
- Language interfaces (Java, C#, Swift, JavaScript/WASM, Python, C++, C, Objective C, Go)
- Implementation tutorials for every language
- Developer guides and demo code within SDK
- Code snippets, full examples, and best practices within our developer portal
- Our team will also work with you from start to finish to manage the project and offer support to your team on all implementation work.
How do I contact Eclypses?
The Eclypses team can be reached by emailing [email protected].
