inWebo Local Authorization (IWLA) framework

 

inWebo access security for automotive and mobility services  

Using a smartphone to secure user access to applications such as Office 365, a healthcare provider portal, or a mobile banking portal is now common practice. inWebo has been providing a secure MFA solution precisely for that purpose since 2011.

However, granting access to an ‘object’ such as a rental car, a hotel room, a booked seat in a train is done by verifying claims presented by the user, usually in the form of a ticket, a badge, or a key. inWebo now provides a security framework called inWebo Local Authorization (IWLA). IWLA’s purpose is to replace these “weak” keys with secure digital keys that can be distributed over-the-air to users’ smartphones .

Why and when do you need IWLA?

Granting access to a web application relies on an authentication component to verify the user identity (thanks to a password, a secure MFA solution) and on an authorization component to verify the permissions of that user. Both components are provided by servers hosted with the application or in the cloud.

Now let’s assume that the object that needs to grant access or authorization is either not permanently connected to the Internet and/or can be accessed by multiple users, known or unknown, with customized permissions. Or even that the user requesting access using her smartphone has no Internet connectivity. This is typically the case of a rental car, a flexible office space, or a hotel room, just to name a few. These objects need to be able to verify claimed permissions and to grant access locally, anonymously, and securely.

These are the situations for which IWLA has been designed. IWLA works with local connectivity only (such as BLE or sound), for shared objects that don’t or can’t maintain an authorization component for all their possible users but still need to grant conditional access based on time, duration, or user profile characteristics for instance.

IWLA framework

inWebo Local Authorization (IWLA) framework consists of the following components:

  • An API: it is used to issue, monitor, or revoke smart locks (for objects) and virtual keys (for users). These operations happen in FIPS-certified security appliances (HSMs) and the result is encrypted end-to-end from our HSMs to the user smartphone (for a virtual key), or to the object (for a smart lock). Both locks and keys are issued on demand, only once. You can therefore be certain that no one can steal a “database” of locks or keys in your servers and get free access to objects that you operate.
  • A library for smartphone Apps: it is used to securely handle digital keys stored in the user’s smartphone. That library needs to be integrated into the mobile App that you provide to the users.
  • A library for objects: it is used to verify user access requests and claims. That library needs to be integrated into the software or firmware of the object. In a compatibility mode, IWLA can be used to emulate mobile credentials recognized by objects that are not IWLA-aware.

Want to learn more?

The best way would be to schedule a demo and to discuss your use cases with our experts. You can also ask us a white-paper if you first need some material to think about it.

Request a demo       Get White-Paper