When you become a REL-ID customer, you get the following components:
REL-ID has been built from the ground up with developers in mind. App developers can take the device-aware REL-IDSDK and easily embed it into any mobile or desktop application with a common set of API definitions and functions. The REL-IDserver APIs provide easy and simple interfaces to integrate your existing identity management and security backend processes.
On the client side, we currently support iOS, Android, Windows, OSX and Linux. The core of REL-IDSDK is built in endian-neutral ANSI-C, making it easily deployable and portable to almost any operating system. Because of the nature of our device-fingerprinting process and endpoint threat detection capabilities, the SDK core is wrapped in a device-specific binary for each operating system.
On the server side, the REL-
There are a number of different multi-factor authentication solutions on the market. You could classify them as either active or passive. Most of the active MFA solutions force you to download a separate standalone app, and all of them still require your users to remember and enter a password or PIN, impacting the user and brand experience. Passive MFA solutions operate by gathering environmental information and feeding that into a common database (sharing your customer information with other subscribers) and using algorithmic techniques that are non-deterministic and operate on a blacklist model.
REL-ID operates entirely within your app using cryptographic techniques tied to your identity model. The result is an authentication experience that is easy and simple, doesn’t require a different app, and is entirely deterministic and whitelist based. That means no more false positives or missed attackers because of device masking. There is also no need to put your customer information into a 3rd party operations center or database.
When building secure apps that can support digital business, there are a number of considerations that only an embedded SDK approach can address.
App Wrapping is a convenient way to add security to an already developed application, but it has its limitations. For one, this type of solution only works for apps that are not being distributed through the platform app stores (like Apple’s App Store or Google’s Play Store) because of the rules they have to block the spread of malicious apps. This makes this technique problematic for consumer apps. Secondly, app wrapping modifies the app binary in a way that makes app fingerprinting and app modification detection ineffective, removing a critical protection and increasing your attack surface.
More importantly, decoupling security from the app development process means your app developers no longer have visibility into the security layer and its protections. That means they are limited in how they can use that security and find it harder to build a user-friendly app that can gracefully handle scenarios that can be addressed with user involvement, a critical factor in consumer-facing apps.
App Injection is the process of introducing external code into or around an existing app, often replacing linked libraries within the code. While decoupling security from app development, it makes your apps brittle because app injection can make it hard to keep pace with OS changes (any change to a linked address space at the OS level often requires a change to the injection bridge). And injection techniques typically work on dynamically linked (e.g. linked at runtime) libraries used by the app for services within the OS layer.
Similar to app wrapping, this technique ends up modifying the app binary in a way that makes app fingerprinting and app modification detection ineffective, removing a critical protection and increasing your attack surface.
More importantly, decoupling security from the app development process means your app developers no longer have visibility into the security layer and its protections. This limits their ability to use that security and makes it harder to build a user-friendly app that can gracefully handle scenarios that could be addressed with user input.
The way TLS was designed to provide end-to-end data integrity and privacy
As your mobile app becomes central to your digital strategy and your security model, you have to take channel security into your hands. That means ensuring data is encrypted end-to-end, and that the channel is man-in-the-middle proof, only accepts connections from known endpoints, is mutually authenticated and is managed from within the app itself. REL-ID's RMAK protocol gives you all this and more.
Not entirely. Done correctly, SSL pinning can address a number of the vulnerabilities that TLS has. But doing it correctly at scale is hard and introduces a great deal of complexity into your DevOps model. The use of SSL pinning is frequently at odds with your CDN model—introducing rigidity into your environment that clashes with your agile digital strategy. On top of that, pinning isn’t a complete answer. It only identifies that server and says nothing about the client. By its nature, it is unidirectional, and therefore inadequate in the face of current threat vectors.
REL-ID integrates directly and transparently into your DevOps model, eliminating the operational overhead and complexity that SSL pinning introduces. RMAK is a mutual and simultaneous security protocol, which addresses some of the more dangerous threat vectors organizations face.
At Uniken, we’re a big fan of standards. That’s why we’ve worked hard to ensure that REL-ID for your security infrastructure allows you to continue down a standards-based authentication path while actually improving its security and usability.
Both FIDO and OpenID Connect rely on TLS, which is known to have vulnerabilities. Combining REL-ID's man-in-the-middle and mutually authenticated secure channel with these standards allows us to close one of the biggest vulnerabilities that both these standards have - exposure to TLS hacks and structural vulnerabilities.
While OpenID Connect has made it quite easy to standardize the authentication process, using MFA with OpenID Connect is still a pain. REL-ID makes it easy to simplify the MFA experience in an OpenID Connect flow. It also makes it easier for an OpenID Connect Identity Provider to leverage transaction verification as a way of ensuring authentication grants are verified.
While FIDO is an excellent solution to eliminating passwords, it doesn’t address all the business needs related to making connecting safe, leaving that up to the app developer. As such, it is just one part of the whole security canvas. Using the REL-ID security platform combined with FIDO allows you to get the benefits of standardization (like a whole range of FIDO compliant authenticators) while also getting the protections you need to reduce your attack surface, like device rootkit/jailbreak/malware detection, device fingerprinting, mutual & simultaneous authentication, and end-to-end data security.