REL-ID Frequently Asked Questions

What is included in the REL-ID solution?

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

  1. REL-IDSDK: An embeddable client library that enables app developers to implement the security capabilities that REL-ID provides in their own native app.
  2. REL-IDgateway: Our edge-server is a horizontally scalable soft-appliance that can be deployed within your on-premises or cloud environment that protects your infrastructure and enables authenticated secure communications to it from the SDK using the RMAK protocol.
  3. REL-IDserver: This server provides built-in support for various policy controls based on the information gathered by REL-IDSDK on the client. It can integrate with existing authentication services and authentication stores, as well as third-party risk engines to dynamically drive authentication policy. It also supports the REL-IDverify service which adds the capability for enterprises to initiate push notifications and then subsequent, on-device transaction approval requests to the user over the secure authenticated channel.

How does REL-ID integrate with our existing security tools and infrastructure?

REL-ID was built to provide absolute flexibility for choice around security infrastructure. The REL-IDSDK can be integrated with different authentication toolkits, and can support any FIDO certified biometric authenticator. The REL-ID gateway can integrate with identity stores like LDAP and ActiveDirectory, as well as authentication and single-sign-on (SSO) services inside your enterprise.

How easy is it to develop a REL-ID secured app?

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.

What platforms does REL-ID support?

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-IDgateway and REL-IDserver components are horizontally scalable soft-appliances that can be deployed on-premises or in your private or public cloud on Linux.

I need a security solution that can scale to the needs of my business. How scalable is REL-ID?

REL-ID has been built for performance and speed, designed for consumer and IoT scale deployments. Our REL-IDgateway has been scaled across millions of users by large financial institutions over the past two years.

How is REL-ID different from other Multi-Factor Authentication solutions?

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.

What advantage does REL-ID's direct API integration approach have over other methodologies?

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.

Why is REL-ID’s embedded SDK approach better than App Wrapping?

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.

Why is REL-ID’s embedded SDK approach better than App Infusion/Injection?

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.

Why is TLS not good enough?

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.

Doesn’t SSL Pinning solve my TLS vulnerabilities?

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.

How does REL-ID fit in with open standards like FIDO and OpenID Connect?

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.

LET'S GET IN TOUCH

LET'S GET IN TOUCH