Porta: Notes for IT Review

Porta is a small Windows service that runs on a machine in your lab, typically the PC attached to a qPCR instrument. Its job is to let Clarida read run data from that machine, so results reach your analysis without anyone copying files onto a USB stick or emailing an export.

It is deliberately small. The agent does connectivity, identity, and a folder-reading capability; that is the whole of the core. Instrument-specific integrations are isolated in separate components, each its own executable, that can be switched off individually.

One such component exists today, for the Roche LightCycler 480. It reads finished runs from that instrument’s own database rather than waiting for someone to export a file. It is installed alongside the agent but does nothing until a member of your workspace configures it, and it can be blocked on the machine itself.

Porta connects outbound to Clarida over TLS on the standard HTTPS port and keeps that one connection open. Registration, status, and file requests all travel over it. The agent refuses to run over an unencrypted connection: a plain-HTTP address is rejected outright, except for a loopback address during local development.

What this means for your firewall

• No inbound firewall rule is required. Porta never asks to be reachable from outside.
• No port forwarding, no static IP, no VPN, and no DMZ placement.
• Standard outbound HTTPS on 443 is sufficient. If your network already allows machines to reach the web, Porta needs nothing further.
• The connection is initiated by the agent and terminated by Clarida. There is no route from the internet to the lab machine.

The one listening socket, and its scope

Porta serves a small setup page on the lab machine itself, so that connecting the agent does not require a command line. It binds exclusively to the loopback address 127.0.0.1 on port 7676, so it is reachable only from a browser on that same machine, and not from any other computer on your network, including one on the same subnet.

We call this out rather than claiming "no listening socket at all", because a port scan of the machine will show it and we would rather you read about it here first. The page runs whenever the service does, not only during setup, so the machine’s owner can always check what is being shared without needing Clarida to tell them. It shows connection status, the folders configured, and which capabilities are active; it never returns the private key or an enrollment code.

It is worth being exact about what loopback binding does and does not give you: it means no other computer can reach the page, but it is not an authorization check against the machine’s own users. Any account able to log in to that PC can open it. Treat access to the lab machine itself as the boundary, as you would for the instrument software already on it.

Porta authenticates with an Ed25519 keypair that it generates on your machine. Only the public key is ever sent to Clarida. On every connection the agent proves who it is by signing a fresh challenge from the server.

The practical consequence is worth stating plainly. Clarida does not hold, and therefore cannot leak, any secret capable of impersonating your agent. A breach of our systems does not yield a credential that connects to your lab.

How the agent is first authorised

• A member of your workspace generates a one-time enrollment code in Clarida.
• That code is pasted into the local setup page on the lab machine. It is short-lived, single-use, and scoped to one workspace.
• The agent generates its keypair, registers the public key, and the code is consumed. From then on the durable keypair is what authenticates.

Revocation

A connector can be revoked from Clarida at any time, and revocation is permanent. A revoked connector cannot be un-revoked, because restoring it would re-trust the very key that prompted the revocation. A revoked agent is refused when it authenticates, regardless of what remains installed on the lab machine.

If a machine is lost, stolen, or decommissioned, revoking the connector is sufficient to cut it off, and you do not need access to the machine. Enrollment codes are separate and short-lived: they are valid for 24 hours, single-use, and stored only as a hash, so an unused code cannot be recovered from Clarida.

The endpoint that accepts an enrollment code is rate limited, and a failed attempt does not reveal whether a code was wrong, expired, or already used. The code itself carries around 192 bits of randomness, so guessing one is not a practical attack; the limit is there because bounding repeated attempts on the one endpoint that accepts a credential is worth doing regardless.

The agent’s private key is stored on the lab machine, protected by the Windows Data Protection API (DPAPI) at machine scope. It is not stored as readable text.

Machine scope is the property that matters: the key is bound to the machine that created it. Copying the configuration file to another computer yields nothing usable, because the key cannot be unprotected anywhere else. An attacker who exfiltrates the file does not obtain a working credential.

Machine scope binds the key to the machine, not to a privilege level, so the file’s access control is the second half of the protection rather than a nicety. The installer sets it explicitly: inherited permissions are replaced so that only the local SYSTEM and LOCAL SERVICE accounts and members of the Administrators group can read the directory. An ordinary logged-in user on that machine is denied access to the file.

Both halves matter, so the agent checks the second one rather than assuming it. At startup it reads the permissions on its own state folder, and if that folder can be read more widely than it should be it says so, both on its setup page and in its log. It reports; it never silently changes permissions itself. That way a machine set up by some route other than our installer cannot end up quietly less protected than this page describes.

Porta is a Windows product and this protection is a Windows mechanism. The agent also runs on other platforms for development and testing, where no equivalent protection is applied. That build is not what we distribute.

Nothing, until you configure it. A freshly installed, freshly enrolled agent serves no folders and is connected to no instrument. Someone in your workspace must explicitly name each folder, or supply an instrument’s address and credentials, before Porta can read anything at all.

Confined to the folders you name

Each configured folder is a root, and every requested path is resolved and then proven to lie inside its root before anything is read. Paths containing "..", absolute paths pointing elsewhere, and symbolic links that escape the folder are all refused. The check compares the fully resolved path, so a symlink cannot be used to step outside.

This is what makes "access to these folders, not the whole machine" a real boundary rather than a convention. Without it, the read capability would amount to arbitrary file access on a lab PC.

Requested, never volunteered

Porta does not watch folders and does not push files up on its own. A person in your workspace requests a listing or a specific file, and the agent answers that request. The lab machine stays authoritative; Clarida reaches in only when asked.

That design also avoids a practical failure: qPCR instruments write run files incrementally, so an agent pushing on file-change would ship half-written runs. Letting a human pull when the run is known to be finished is both safer and more correct.

Individual file reads are capped at 25 MiB. A larger file fails immediately rather than transferring.

Continuously

While connected, Porta reports operational status: the agent version, which capabilities are installed and enabled, and basic machine metadata for troubleshooting, namely hostname, operating system, architecture, and runtime. This set is governed by a schema that deliberately excludes personal data; the logged-in user, internal IP addresses, and instrument serial numbers are not reported.

On request

Folder listings and file contents, for the folders you configured, when a workspace member requests them. On a configured instrument, the list of runs and the run data itself, likewise only when asked. Nothing else.

What travels the other way: an instrument credential

Connecting to an instrument needs a login for it, and that is the one secret this system carries. It is worth being exact about where it lives, because the honest answer is narrower than "we store it securely".

• You type it once, in Clarida, when configuring the instrument. It travels down the existing encrypted connection to the agent.
• Clarida does not keep a copy. The agent mirrors its settings back so the interface can show host, port and username, and the credential is excluded from that mirror by an allowlist: fields are published only if named as publishable, so a new field is withheld by default rather than exposed by oversight.
• It is stored only on the lab machine, protected by the same Windows mechanism as the agent’s own key, in the same restricted directory.
• It cannot be read back. The password field in Clarida is write-only, so leaving it blank keeps whatever the machine already holds, and there is nothing to display because nothing was kept.

The consequence, stated the same way as for the agent key: a breach of our systems does not yield your instrument password, because we do not have it. What we hold is the fact that one is configured, and whether it last worked.

What the agent will not do

• It does not execute arbitrary commands. The agent implements a fixed, named set of capabilities decided at build time; an instruction naming anything else is refused rather than run. There is no shell invocation, and no mechanism by which text from the server becomes a command.
• It does not modify, move, or delete anything it reads. Both capabilities list and read; neither has a write operation. On an instrument it signs in, reads finished runs, and signs out — it does not alter the instrument’s database or start a run.
• It does not scan the machine, enumerate drives, or index anything outside the configured folders.
• It does not reach across your network on its own. The instrument capability connects to one address you supply, and only when asked; it discovers nothing and probes nothing.
• It does not update itself. There is no update mechanism in the agent at all; new versions are installed deliberately by an administrator. Porta never downloads or runs code on its own.

To be precise about the boundary: Clarida chooses which of those fixed capabilities runs and supplies its parameters, including, for the folder capability, which folders are served. What Clarida cannot do is introduce a new operation, and what it cannot override is a block set locally on the machine.

A record you hold yourself

The agent also writes its own log, on the lab machine, in a folder your administrators can read. It records what the agent did: when it started and stopped, when it connected, every request it received and whether it succeeded, which file was read and how large it was, when a capability was blocked or unblocked locally, and when the connector was paired or re-paired.

This exists so that our claims on this page are checkable without our cooperation. You do not have to take our word for what the connector reached: read the machine’s own log, or point your log collector at it. It records paths and sizes, never file contents and never key material, and it is size-capped so it cannot fill a disk.

To be straight about its limits: the agent writes this log about itself, so it is tamper-evident rather than tamper-proof. Anyone with administrative access to that machine could alter it. Its value is that it is independent of Clarida, not that it is impossible to forge.

Porta installs as a standard Windows service, set to start automatically so it survives a reboot. It runs under the machine’s LocalSystem account. Installation requires administrator rights, as service registration and writing to Program Files do; using the agent afterwards does not.

It ships as a self-contained executable with its own bundled Python runtime, so nothing needs to be pre-installed and Porta neither depends on nor interferes with any other software on the machine.

The installer is code-signed

Both the installer and the agent executable inside it are signed by Clarida BV, and every signature is timestamped so it stays valid indefinitely. If you open the installer’s properties, the Digital Signatures tab names us; during installation, Windows shows Clarida as the verified publisher rather than "Unknown".

Signing happens in our build pipeline against a certificate held in a cloud signing service. No signing key exists on any developer machine, which is the property worth having: a compromised laptop cannot produce something that appears to come from us.

You will still see a SmartScreen warning

Being signed and being recognised are different things, and we would rather you hear this from us than meet it unexplained. Windows will show "Windows protected your PC" and describe the app as unrecognised. Choose "More info" to reveal the "Run anyway" button. It is not on the first dialog, which makes the download look blocked when it is not.

The reason is that SmartScreen builds reputation against a specific file, accumulated from how many people have downloaded and run it. A newly published build has no such history, so it is unrecognised regardless of who signed it. Our certificate is an organisation-validated one rather than the extended-validation type that carries immediate reputation, so each new version starts that count again.

What the signature does give you is the thing worth checking: the publisher named in that dialog is verified, not self-asserted. An unsigned installer would show no publisher at all. If your policy does not permit clicking through SmartScreen, tell us. That is a reasonable position and we would like to know it is blocking you.

Instrument capabilities are separate components rather than part of the core. Each is its own executable, launched as an isolated process, so a fault in one cannot destabilise the connection or the agent itself. Each is signed on its own, so the signature you check on the agent is not doing double duty for code it does not contain.

The LightCycler 480 component is a 32-bit executable, unlike the 64-bit agent, because Roche’s interface is a 32-bit Windows component and a 64-bit process cannot load it. That is why the installer carries a second, smaller Python runtime; both are listed below. It is installed alongside the agent and, like the folder capability, does nothing until configured and can be blocked on the machine.

Local control over what is enabled

Each capability sits at one of three levels: installed, enabled, or blocked. Enabling is done from Clarida by your workspace; blocking is done locally on the machine, from the setup page.

A local block wins. It is stored outside the settings that Clarida can push down, so an instruction from the platform cannot clear it. If the machine owner blocks file access on that PC, no action in Clarida re-enables it; someone has to unblock it at the machine. Granting instrument access and granting file access are also separate decisions, and neither implies the other.

Uninstalling stops and removes the Windows service, and deletes the agent’s stored credential. The private key does not survive an uninstall, so a decommissioned machine is not left holding a key that still authenticates.

This is not offered as a prompt during uninstall. Whether an orphaned credential matters is not a judgement the person clicking Uninstall can reasonably make, so the safe behaviour is the only behaviour. An administrator who intends to preserve an enrollment should back the configuration up beforehand; otherwise the machine simply re-enrolls with a fresh code.

Upgrading is unaffected. Installing a new version over an existing one does not clear the credential, so a version update never forces re-enrollment.

One file is left behind: the service wrapper’s own rotating log, written at runtime beside the program files. It contains service start/stop records, no credentials and no data. It can be deleted freely.

Uninstalling does not revoke the connector in Clarida; the two are separate actions. An uninstalled agent stops connecting and shows as offline, but its record stays until someone revokes it. We recommend doing both: uninstall on the machine, then revoke in Clarida to close the record.

Either one alone is enough to stop the agent working, and for a lost or compromised machine revocation is the one that matters, since it needs no access to the machine. The private key existed in exactly one place and uninstall deletes it, so an uninstalled agent cannot reconnect even if its record is still open.