EviBLE HID transforms a compatible Android device into a sovereign Bluetooth HID keyboard for secure, offline and Zero-Agent input. Therefore, users can send deterministic keyboard input to supported terminals without installing Freemindtronic software on the host.
Offline by design
No host software
Host layout profiles
Fail-closed input
Bluetooth keyboard
No cloud required
EviBLE HID focuses on the final secure-input path between a Freemindtronic-controlled Android environment and a target terminal. Instead of copying credentials through a clipboard or synchronizing them through an online service, EviBLE HID converts authorized input into standard keyboard reports and sends them directly through Bluetooth HID.
Furthermore, the technology separates sensitive data ownership from transport. Freemindtronic applications and NFC HSM technologies remain responsible for secrets, authentication and user authorization, while EviBLE HID acts only as the controlled HID delivery layer.
EviBLE HID makes the Android source device behave as a Bluetooth keyboard toward the destination terminal. Therefore, the host interacts with a standard HID device instead of a proprietary credential protocol. This design reduces host-side dependencies and, importantly, keeps deployment simple.
The technology does not need a cloud relay. Moreover, the destination computer does not need an EviBLE driver, browser extension, password-manager plugin or background agent. Once Bluetooth pairing exists, EviBLE HID can establish the HID session and send validated keyboard reports to the selected active host.
| Layer | Responsibility | Security principle |
|---|---|---|
| NFC HSM / Freemindtronic | Secret ownership and authorization | Secrets stay under Freemindtronic control |
| FMT Secure Input | Chooses the authorized input operation | Explicit user-controlled action |
| EviBLE HID | Transforms approved input into HID reports | No secret persistence in the HID provider |
| Bluetooth HID | Delivers standard keyboard events | Host compatibility without an agent |
| Host terminal | Receives keyboard input | Must still be treated as an independent trust domain |
A standard Bluetooth HID connection does not tell a keyboard which operating-system layout the host currently uses. Consequently, blindly sending the same HID sequence can produce the wrong character on another layout.
EviBLE HID solves this problem with its Zero-Agent calibration architecture. For an unknown terminal, EviBLE can send carefully selected, non-sensitive HID probes inside a dedicated calibration workflow. The user then confirms the visible result. Therefore, the system can progressively narrow the candidate layouts without installing software on the host.
First, EviBLE identifies the Bluetooth host. Next, it checks whether a validated profile already exists. If no HIGH-confidence profile exists, EviBLE starts calibration. Then, it uses a small number of safe observations to identify the keyboard layout. Finally, the user confirms the result before Secure Send becomes available.
Once EviBLE stores a valid HIGH-confidence profile, it can verify the host identity and layout metadata on reconnect. Consequently, a known unchanged terminal can reach AUTO_SELECTED / HIGH without sending another calibration probe.
Correct character mapping matters especially when users inject passwords, recovery codes or administrative commands. Therefore, EviBLE HID does not treat an uncertain keyboard layout as acceptable for sensitive input.
The Secure Send gate uses explicit confidence states. A HIGH state means EviBLE has a sufficiently validated host-layout profile. Conversely, LOW or NONE keeps sensitive Secure Send blocked. Additionally, recalibration clears the previously trusted state until the new result receives explicit confirmation.
International keyboards map the same physical HID usage to different characters. Therefore, reliable multilingual Secure Input requires more than a translation table.
Freemindtronic built a common layout architecture that converts pinned operating-system layout sources into validated EviBLE layout packs. Moreover, Windows, Linux and macOS adapters feed the same canonical runtime model. Consequently, new keyboard layouts can scale through data and provenance rather than through duplicated Java classes.
| Platform family | Validated packs | Current baseline |
|---|---|---|
| Windows | 11 | en-US, fr-FR, de-DE, es-ES, it-IT, pt-PT, ro-RO, ca-ES, ru-RU, uk-UA, Arabic |
| Linux | 11 | Equivalent canonical host-layout families |
| macOS | 11 | Equivalent canonical host-layout families where native sources were validated |
| Total | 33 | Runtime parity validated |
Furthermore, the Factory verifies provenance, hashes, deterministic regeneration, coverage and runtime compatibility. Therefore, the architecture can expand toward a broader international catalog without redesigning the HID engine.
Some writing systems depend heavily on host IMEs. Consequently, EviBLE does not claim arbitrary Unicode typing through standard HID where the host input method remains essential.
Users may pair EviBLE HID with several computers or terminals. However, the source device keeps an explicit active target for keyboard delivery. Therefore, a Secure Input operation cannot accidentally broadcast to every bonded host.
When a known host reconnects, EviBLE can restore its persisted layout profile if the profile identity, Factory epoch and layout fingerprint still match. Consequently, validated hosts can return directly to the correct keyboard configuration without repeating calibration.
Existing Bluetooth bonding also remains usable. In other words, Zero-Agent calibration does not require users to delete and recreate a previously established pairing.
The runtime operates locally. Therefore, authentication workflows do not depend on an internet connection, DNS service, external API or cloud account.
Furthermore, keyboard layout resources travel with the validated application build. The production terminal does not fetch mappings from the internet. Consequently, EviBLE HID remains suitable for isolated workstations, restricted environments and offline administrative workflows.
This architecture does not magically make every Bluetooth environment an electromagnetic air gap. Instead, it provides network-independent secure input while keeping the application workflow autonomous from IP networks and cloud infrastructure.
Freemindtronic NFC HSM technologies can authorize access to protected credentials or operational data. Then, the application can route an authorized Secure Input operation through EviBLE HID.
Importantly, EviBLE HID does not need to become the long-term owner of those secrets. Instead, the Secure Input provider receives the authorized operation and emits the corresponding keyboard reports. Therefore, secret management and HID transport remain separated by design.
Moreover, Freemindtronic can keep InputStick as a permanent alternative provider. Consequently, users can choose the HID route that best matches their equipment without abandoning existing deployments.
Users can deliver authorized credentials through keyboard input without first copying them into the destination clipboard. Therefore, the workflow reduces exposure to clipboard history, synchronization utilities and copy-paste interception.
Administrators can use EviBLE HID on supported login forms, local administration consoles and isolated workstations. Moreover, the Zero-Agent approach reduces deployment dependencies on the destination terminal.
Where the destination environment accepts standard Bluetooth HID input at the relevant stage, EviBLE can provide deterministic keyboard reports. However, actual pre-boot Bluetooth support depends on the host firmware and platform implementation.
EviBLE HID can support terminals where operators want to reduce software installation and network dependency. Consequently, the technology is relevant to selected SCADA, ICS, embedded and maintenance workflows, subject to the HID capability and security policy of the target equipment.
Offline Secure Input can also complement break-glass procedures because it avoids dependence on cloud connectivity. Nevertheless, organizations should still apply their normal operational controls, auditing and endpoint protection.
| Property | EviBLE HID |
|---|---|
| Technology type | Bluetooth Human Interface Device keyboard technology |
| Source platform | Compatible Android device with Bluetooth HID Device capability |
| Host software | No Freemindtronic host agent required for standard HID operation |
| Internet requirement | None at runtime |
| Cloud dependency | None at runtime |
| Primary HID interface | Keyboard |
| Host management | Multiple known/bonded hosts, one explicit active HID target |
| Layout engine | Data-driven LayoutDescriptor architecture |
| Validated layout baseline | 33 packs across Windows, Linux and macOS layout families |
| Zero-Agent calibration | Minimal safe HID observations for unknown layouts |
| Known-host restore | Persistent validated profile with zero-probe auto-selection when still valid |
| Secure Send policy | Fail-closed unless layout confidence meets required state |
| Caps Lock handling | LED state monitoring with strict UNKNOWN policy available |
| Secret persistence in HID provider | Not required by the architecture |
| Runtime architecture | Local and autonomous |
| Capability | EviBLE HID | InputStick BLE USB |
|---|---|---|
| Extra USB hardware | No dedicated InputStick required | InputStick USB dongle required |
| Host-side Freemindtronic agent | No | No |
| Transport architecture | Android acts as Bluetooth HID device | Android communicates with InputStick, which exposes USB HID |
| Zero-Agent layout calibration | Yes, EviBLE architecture | Not the same host-fingerprinting architecture |
| Per-host validated layout profile | Yes | Layout selection follows the InputStick integration model |
| Secure Send fail-closed layout gate | Yes | Different architecture |
| Existing Freemindtronic deployments | New additional provider | Permanent supported provider |
Therefore, EviBLE HID does not replace InputStick by architectural necessity. Instead, Freemindtronic can expose both through a common Secure Input abstraction and allow users to select the appropriate provider.
EviBLE HID moves secure keyboard delivery closer to the Freemindtronic-controlled device while keeping the destination terminal free from proprietary host software. Therefore, it creates a practical bridge between sovereign NFC HSM workflows and standard human-interface protocols.
Moreover, Zero-Agent host-layout calibration addresses a problem that conventional HID keyboards usually leave to the user: selecting the correct mapping for each terminal. Once EviBLE validates that mapping, it can remember the host and restore the correct profile later.
Ultimately, EviBLE HID combines standard Bluetooth keyboard compatibility, offline operation, international keyboard intelligence, explicit fail-closed Secure Send and Freemindtronic NFC HSM integration in one sovereign Secure Input architecture.