Security

Table of Contents

1. Overview
2. Supply Chain Security
3. Security Model & Limitations
4. File Locations
5. Changing Keys
6. Exporting and Recovering Services
7. Windows Reinstallation or Machine Migration
8. Best Practices
9. Troubleshooting

Overview

Servy securely encrypts stored passwords, environment variables, and process parameters using AES encryption. If the database is compromised, sensitive values remain protected and cannot be viewed in plain text.

The AES encryption key and initialization vector (IV) are protected using Windows Data Protection API (DPAPI) with the LocalMachine scope. This ensures the key material can only be decrypted on the same machine where it was created, and is protected by the operating system.

DPAPI keys are bound to the current Windows installation. After a clean OS reinstall or server migration, encrypted secrets cannot be recovered. Export each service before the change and import it into the new installation to retain its secrets.

Starting with Servy v6.5+, Servy implements authenticated encryption using AES-256-CBC with HMAC-SHA256 and a dynamic IV to ensure both data confidentiality and cryptographic integrity. This modern approach utilizes a unique, randomly generated initialization vector for every operation to prevent pattern recognition and employs a Hash-based Message Authentication Code to detect any unauthorized tampering before decryption occurs. To maintain a unified security architecture, Servy leverages a salted HKDF (HMAC-based Key Derivation Function) to derive independent sub-keys for encryption and authentication from the protected master material. This implementation is fully backward compatible with previous versions because the system automatically detects the version of the encrypted payload by identifying the v2 versioning marker or falling back to legacy static IV logic for v1. This process ensures that existing passwords and parameters remain accessible without requiring manual data migration.

All official Servy executables and installers are digitally signed using a trusted code-signing certificate provided by the SignPath Foundation. This allows users and automated systems to verify the authenticity and integrity of Servy binaries.

Servy has been reviewed by Microsoft Security Intelligence and is classified as safe. It performs only standard installation and service-management operations and does not include malware, adware, or unwanted software. Servy passes VirusTotal scans and is distributed through well-known package managers including Windows Package Manager (WinGet), Chocolatey, and Scoop. Official releases are available from GitHub and these package managers.

Supply Chain Security

Servy publishes Software Bills of Materials (SBOMs) for official releases in CycloneDX format. These SBOMs document all production dependencies used to build Servy and allow users and organizations to independently assess supply-chain risk and license compliance.

The Servy source repository uses GitHub Dependabot to monitor third-party dependencies for known security vulnerabilities. When vulnerabilities are identified, Dependabot generates security alerts and notifications to update affected dependencies, allowing issues to be reviewed and updates to be applied as appropriate.

Combined with reproducible builds, signed binaries, and trusted distribution channels, this provides transparency into Servy's dependency graph and reduces supply-chain risk.

Security Model & Limitations

Servy stores service definitions, runtime state, and operational metadata in a shared configuration directory located at %ProgramData%\Servy. This directory contains Servy’s SQLite database, configuration files, and supporting binaries required for service operation.

Access to %ProgramData%\Servy is expected to be controlled using standard Windows filesystem permissions (ACLs). Only trusted service identities (for example, SYSTEM, Administrators, or designated service accounts) should be granted Read and Write access. Regular user accounts should not have write permissions.

This design aligns with standard Windows service architecture, where isolation and privilege boundaries are enforced by the operating system through service identities and ACLs, rather than by duplicating configuration stores or introducing additional sandboxing layers. Keeping a shared configuration directory allows Servy to remain lightweight, predictable, and fully compatible with native Windows service management.

Because the configuration directory is shared, Servy does not implement logical isolation between services that have write access to %ProgramData%\Servy. All services operating with such access are considered to be within a single trust boundary. In practical terms, this means:

• Shared Influence: Any account with write access to %ProgramData%\Servy can modify shared configuration or state and may influence the behavior of other Servy-managed services.
• Trust Assumption: All service identities granted write access to the Servy configuration directory must be mutually trusted. A compromise of one such identity may allow indirect influence over other services.
• Intended Environments: Servy is designed for single-tenant or trusted environments, such as dedicated application servers, internal infrastructure, CI/CD agents, and developer workstations.
• Non-Goals: Servy is not intended to provide tenant isolation, adversarial security boundaries, or per-service sandboxing.

If your security requirements demand strong isolation guarantees between services running under different identities, consider using one of the following approaches instead of relying on Servy-level separation:

1. Machine Isolation: Run unrelated workloads on separate physical or virtual machines.
2. Containerization: Use Windows Containers or Docker to enforce filesystem and process isolation.
3. Hypervisor Boundaries: Deploy services on separate operating system instances to achieve hardware-enforced isolation.

Recommended Permissions

For typical Servy deployments, configure the %ProgramData%\Servy directory with the following Windows ACLs:

Identity	Permissions	Notes
SYSTEM	Full Control	Required for service operation
Administrators	Full Control	For management and troubleshooting
Servy service account(s)	Modify	Allows service to read/write configs, DB, and supporting binaries
Regular users / other accounts	Read or None	None is preferred to prevent users from viewing sensitive operational metadata

Important

Do not grant write access to untrusted user accounts. All service accounts with write permissions are assumed mutually trusted and part of a single Servy trust boundary.

File Locations

Servy stores the AES key and IV in the following files:

# AES Key
%ProgramData%\Servy\security\aes_key.dat

# AES IV
%ProgramData%\Servy\security\aes_iv.dat

Changing Keys

You can replace the AES key and IV by modifying the files above.

Changing either file will make all previously encrypted passwords impossible to decrypt.

Only replace these files if:

• You are setting up a new Servy installation
• You have a migration plan to re-enter or re-encrypt credentials

Exporting and Recovering Services

Service configurations can be exported to XML or JSON for backup or migration purposes.

Important considerations:

• Passwords and other secrets are exported in plaintext
• Exported files must be treated as highly sensitive
• After importing services into a new installation, secrets are re-encrypted during service installation using the new system's DPAPI keys

Because exported configuration files may contain secrets in plaintext:

• Exports should be stored securely
• Access to export files should be restricted
• Export files should not be committed to source control or shared insecurely

Once services are installed, secrets are protected at rest using DPAPI and are no longer stored in plaintext.

Windows Reinstallation or Machine Migration

Because DPAPI keys are tied to a specific Windows installation, encrypted secrets cannot be recovered after a clean OS reinstall.

If you want to recover services from a previous Servy installation, you must:

• Export services from the original installation
• Import the exported services into the new installation
• Install each service individually

Service definitions and non-sensitive configuration are restored automatically.

Best Practices

• Backup first: Keep a secure backup of the existing key and IV before making changes
• Restart required: Restart the Servy app after modifying these files
• Restrict access: Limit access to the %ProgramData%\Servy\security folder so only trusted administrators can read/write these files
• Do not share across machines: Because DPAPI LocalMachine scope is used, copying the files to another machine will not work

Troubleshooting

• Encryption errors: If Servy cannot decrypt stored passwords, verify that the key and IV files exist and are intact
• Corrupted files: If either file is corrupted or partially overwritten, previously encrypted passwords will be unrecoverable
• Permissions issues: Ensure Servy app have sufficient access to read the key and IV files in %ProgramData%\Servy\security
• User account mismatch: Although LocalMachine scope is used, very restrictive security settings may prevent some service accounts from accessing the files
• Service using a domain account does not start after reboot: See solution here