REL-ID Frequently Asked Questions

On the client side of our security platform, we currently support IOS, Android, Windows, OSX and Linux operating systems. The core of REL-ID’s single software development kit (SDK) aligns with endian-neutral ANSI C standards, making it portable and easily deployable to almost any operating system. It provides the security protection and capabilities your business needs — endpoint protection, validation, authentication, and secure omni channel connectivity — without killing performance and battery life.

Because of the nature of the mobile app security solution’s device fingerprinting process and endpoint threat detection capabilities, the SDK core is wrapped in a device or development environment specific binary depending on the platform. We currently support the following developer interfaces:

• Native IOS Objective C
• Native Android Java
• React Native
• Cordova
• Xamarin

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.

We also offer to our customers and their developer teams an open-source, javascript-based reference app built using REL-IDSDK that demonstrates its power and capabilities. Based on React Native, the open source solution helps our customers bring down the time-to-market for their new products with REL-ID security from months to weeks.

When you become a REL-ID customer, you get the following components:

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.

1. As a business, you want full control of the customer experience with security integrated—something post-development solutions have a tendency to break.
2. Direct integration into the app ensures that all data leaving the app process space is encrypted, even before it hits the OS provided transport layer such as TLS or the OS provided storage layer.
3. Direct integration allows for techniques that provide for validation of the app itself to ensure it hasn’t been tampered with, is running on a non-jailbroken or rooted device, and is free of impacts from malware.
4. Direct API integration combined with static linking of libraries such as the REL-ID API toolkit ensure that apps can’t have their libraries swizzled (replaced), blocking additional threat vectors.
5. If you are distributing your app through the app stores provided by Apple, Google and the various Android handset providers, you have to comply with their publication rules. Those rules and how they tie into the OS platforms require the security to be integrated directly into the application before publication to the app store, and in a way that does not open the app to abuse.

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 is insufficient for organizations trying to do business over the internet. Modern reality has forced organizations to adopt authorized man-in-the-middle services in the form of CDNs and VANs, accept the use of public, vulnerable, and often malicious WiFi networks by consumers, and see the foundation of TLS security get compromised due to rising issues with DNS providers and certificate authorities. All these realities just exacerbate the MITM issues and exposed threat surface TLS has. In a nutshell, TLS just isn’t up to the task anymore.

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.