NelkiraDownload
Menu

Security Statement

Written for the person who has to approve remote access software for a hospital. It says what Nelkira does, and it says what it does not do yet, because a security page that only lists strengths is of no use to someone doing that job.

How a session is protected

  • Encrypted end to end. The two machines agree a key using an ephemeral elliptic-curve exchange (P-256), and everything after that — screen, keystrokes, mouse, clipboard, files — is encrypted with AES-256-GCM, with a separate key in each direction and a counter that prevents a captured message being replayed.
  • A relay cannot read what it carries. Where a session goes through a relay, the relay copies encrypted bytes. It holds no key that would let it read them. This includes relays we operate.
  • From release 0.4.0 the password is proved, not sent. Encryption alone would not stop a relay from running two exchanges and sitting between them. From 0.4.0 both ends prove the access password to each other with a password-authenticated key exchange (SPAKE2, RFC 9382) bound to the two keys they saw, and the password itself never leaves either side. A viewer older than 0.4.0 still runs the check one way: it sends the password, inside the encrypted channel, to whichever machine answers the number. So a sign-in from an older viewer through a hostile relay is not protected against impersonation: that relay could pose as the machine, learn the password and sit in the middle. From 1 May 2027 a PC on 0.4.0 or newer accepts a password only from 0.4.0 or newer viewers. A 0.4.0 viewer never sends the password to a PC on an older Nelkira; it offers only the Allow way in there until that PC is updated.
  • Direct where possible. Two machines on the same subnet are told to connect to each other rather than through a relay. Where Windows Firewall on the machine being reached allows it, the traffic stays on the site; where it does not, the session goes through a relay.

Who can get in

  • A password, or a person clicking Allow. Entering the machine’s access password connects straight away. With no password, the person at the machine is asked to approve, and the connection waits for them. On a PC where Nelkira is installed for use while someone is here, which is what Setup does unless told otherwise, the machine must have someone signed in to Windows and Nelkira running: after a restart it cannot be reached until someone signs in and Nelkira starts. From release 0.5.0 an administrator can instead set a PC up for access when nobody is there, described below. From release 0.4.1 the access password a machine shows is a new one each time Nelkira starts there, and it is never written to disk; a password the owner sets with the Agent__AccessPassword setting stays as set.
  • Remembered devices are revocable tokens, not stored passwords. A device that was let in once may be issued a random token. The machine keeps a hash of the token and the value it checks that device’s proof against, never the token itself. From 0.4.0 a remembered device unused for 90 days is dropped. From release 0.4.1 a new access password, at start or from New password on the Advanced tab, does not forget remembered devices. Forgetting remembered devices on the machine (all at once, with Forget all on the Advanced tab) invalidates their tokens.
  • Stored secrets are encrypted at rest to the machine or to the user account, using the operating system’s protected storage, except the token that registers the machine to your account, which is kept in a plain file. Where Nelkira is installed for use while someone is here, encryption to the machine does not keep them from other people with a Windows account on the same PC: anyone signed in to another account there can read and change the list of remembered devices (from 0.4.0, enough to sign in as one of them; from 0.4.1 that keeps working across new passwords until Forget all), the token that registers the machine to your account and, from 0.4.0, the device key that proves the machine’s number to the relays. On a machine running a release before 0.4.1 the same goes for the access password; from 0.4.1 the password Nelkira makes is kept only in memory, while one set with the Agent__AccessPassword setting can be read by anyone who can read that setting. On a PC set up for access when nobody is there, only administrators and Windows itself can open them (described below). A fixed Agent__AccessPassword stays readable by every account that can read where it is set, including beside Nelkira.exe on a PC set up for access when nobody is there.
  • Failed attempts are limited and are written to the record.

A PC set up for access when nobody is there (from release 0.5.0)

Setup asks “Will people connect when nobody is at this PC?”, with No chosen unless someone changes it. No installs Nelkira for use while someone is here, as above. Yes needs an administrator’s approval, and IT teams can roll it out silently with Setup’s /ALLUSERS option. A PC installed for everyone with release 0.4.x is set up this way when it is updated to 0.5.0, but only after Setup has listed the points below and someone at the PC has chosen Install for everyone, which Windows then asks an administrator to approve unless Setup already runs with one; Cancel, or an update that runs quietly, leaves it on 0.4.x. Choosing Yes means:

  • Nelkira starts with Windows for everyone on the PC, also before anyone signs in. After a restart, a device that connected once with the password and Remember ticked can reach it, at the sign-in screen too, unless someone at the PC pressed Stop sharing: from release 0.5.0 a pause lasts across restarts and updates, and the PC refuses everyone, remembered devices included, until someone signs in there and presses Start sharing. The password is new after a restart and nobody can read it until someone signs in, so tick Remember beforehand. At the lock screen and at administrator prompts, the password currently shown to the signed-in person also works. A connection with no password, which needs someone to click Allow, is refused while nobody is signed in. A session someone let in with Allow follows that same person into administrator prompts and the Ctrl+Alt+Del screen, but ends at the lock and sign-in screens, and is never carried over to another person who signs in. A helper is not certain to see a picture of the lock, sign-in, Ctrl+Alt+Del and administrator-prompt screens. On a test virtual machine without Direct3D 11 graphics, a helper saw the sign-in screen while nobody was signed in, and an administrator prompt, but no picture of the lock screen while someone was signed in, although the helper was let in; the Ctrl+Alt+Del screen was not tried. None of this has yet been checked on a physical PC.
  • A helper who connects can answer Windows administrator prompts, with administrator rights when the person signed in is an administrator.
  • Nelkira lets a helper send Ctrl+Alt+Del. This changes one Windows setting; uninstalling puts it back, and your organisation’s Group Policy, if it sets it, still decides.
  • On a PC set up for access when nobody is there, only administrators and Windows itself can open Nelkira’s files; administrators can still read them. They are encrypted to the machine, which code running as an administrator or as Windows itself can undo.
  • Windows Firewall gets a rule for Nelkira on private and domain networks, for computers on the same network only. On a network Windows calls Public, direct connections stay blocked and helpers reach the PC through the internet.
  • The screen locks when the last helper disconnects; an administrator can turn this off. The ‘Screen shared’ sign shows whenever someone is connected, except on the lock, sign-in, Ctrl+Alt+Del and administrator-prompt screens.
  • Updates install by themselves, also when nobody is signed in, and only while nobody is connected. Nelkira is offline for about a minute while it updates, and the password is new afterwards; remembered devices keep working, unless sharing was paused with Stop sharing, which lasts across the update.
  • It works at the PC’s own screen and keyboard (the Windows console) only, not over Remote Desktop.
  • Uninstalling removes it and puts the Ctrl+Alt+Del setting back. The logs and the record of who connected are kept for your IT team in C:\ProgramData\Nelkira\Kept logs, readable by administrators only, until someone deletes them. Installing again for use while someone is here gives the PC a new number.

What the machine records

Every machine keeps its own record of what was done to it: when a session started, how it was authorised, when it ended, files taken or placed and their names, clipboard transfers by size, screen switches, Ctrl+Alt+Del, and the times the screen was blanked.

Two deliberate choices. The record lives on the machine that was accessed, not on the engineer’s laptop, because evidence of what was done to a computer belongs to whoever owns that computer. And it contains no content — no clipboard text, no file contents, no keystrokes, no screenshots — because a log holding what was on a clinician’s clipboard would be a patient-data breach wearing the clothes of an audit trail.

What the person at the machine can see and do

They approve connections that arrive without a password, they can end any session, and they can forget every remembered device. Ending a session does not stop the next one: someone with the password or a remembered device can connect again at once. From release 0.5.0, Stop sharing keeps everyone out, remembered devices included, until someone at the PC presses Start sharing, also across restarts and updates; on a PC installed for use while someone is here, the pause belongs to the Windows account that chose it. Blanking the screen during a session hides it from people walking past. It blocks local input only where Nelkira runs with administrator rights or, from release 0.5.0, on a PC set up for access when nobody is there; on a PC installed for use while someone is here the keyboard and mouse at the machine still work while the screen is blank. It does not work at the Windows sign-in, lock or administrator-approval screens. It is not, and must not be used as, a way to hide from the machine’s own user. Doing that breaches the Acceptable Use Policy.

What we do not do yet

This list is here because you need it to make a decision.

  • We hold no certification. No ISO 27001, no SOC 2, no HIPAA attestation. We have not been audited by a third party. Where a supplier claims a certification, ask for the certificate; where we claim one, we will publish it here.
  • The session record is not tamper-evident. It is a plain file on the machine, and anyone with a Windows account on that machine can alter or delete it (from release 0.5.0, on a PC set up for access when nobody is there, only administrators can). Making it signed, or sending it somewhere the machine cannot reach, is work we intend to do and have not done.
  • A connection approved by clicking Allow, with no password, is encrypted but not proof against an active attacker in the middle. There is no shared secret to bind the exchange with.
  • A password sign-in from a viewer older than 0.4.0 is not proof against a hostile relay either. A viewer older than 0.4.0 still sends the password to whichever machine answers the number, as described above; a 0.4.0 viewer does not send it to an older PC and asks for Allow there instead. From 1 May 2027 a PC on 0.4.0 or newer accepts a password only from 0.4.0 or newer viewers.
  • Other Windows accounts on the same PC can read and change its machine-wide secrets, as described above, where Nelkira is installed for use while someone is here. A shared PC should be set up for access when nobody is there, where only administrators and Windows itself can open them. A fixed Agent__AccessPassword stays readable by every account that can read where it is set, including beside Nelkira.exe on a PC set up for access when nobody is there.
  • The software is not code-signed, so Windows SmartScreen warns before Setup runs. Check the SHA-256 published on the download page until that changes.
  • No formal penetration test has been carried out. Nelkira has been internally security-tested only. When an outside test is done, we will say who did it and what they found.

Notice dated 22 October 2026. From 1 May 2027, a PC running Nelkira 0.4.0 or newer accepts a password only from Nelkira 0.4.0 or newer (Windows, Linux, macOS and Nelkira Go). Older viewers can still connect when the person at the PC clicks Allow. Update before then at nelkira.com. Until your viewer is updated to 0.4.0, the password still travels inside the encrypted channel to whichever machine answers your number.

Release 0.4.1 reaches PCs in stages; the download page shows the version on offer.

Your part

Most incidents involving remote access software are not defeats of the encryption. They are somebody being talked into giving out their number and password over the telephone. Tell your staff that nobody legitimate — including us, including your own IT team out of the blue — will ring them and ask for those details. See the abuse page.

Telling us about a weakness

Please write to security@nelkira.com. Our disclosure policy sets out what we promise in return, including that we will not take legal action against people who report honestly.

Nelkira Technology Ltd. publishes this statement in good faith and keeps it current. If any part of it is out of date or wrong, that is a defect and we want to hear about it at security@nelkira.com.