Security

Table of Contents

1. Security Overview
2. How We Protect Your Data
   1. Automatic Directory Hardening (ACLs)
   2. Machine-Unique Encryption (Dynamic Entropy)
   3. Cryptographic Key Derivation (HKDF)
   4. Authenticated Encryption (v6.5+)
   5. In-Memory Defense (Memory Zeroing)
   6. Service Account Credentials (SERVY_PASSWORD)
3. Supply Chain & Trust
4. The Servy Trust Boundary
5. File Locations & Recovery
6. Critical Warning: Machine Migration
7. Best Practices
8. Troubleshooting

Overview

Servy acts as a secure vault for your Windows service configurations. We encrypt sensitive data, including passwords, environment variables, and all execution arguments (Parameters, EnvironmentVariables, FailureProgramParameters, PreLaunchParameters, PreLaunchEnvironmentVariables, PostLaunchParameters, PreStopParameters, and PostStopParameters), using industry-standard AES-256 encryption. If the database is compromised, your actual secrets remain unreadable text.

The Double-Lock System

Starting in version 7.9, we use a two-layer defense strategy to keep your secrets safe:

• The Locked Room (ACLs): We automatically restrict who can even view the Servy folders on your hard drive.
• The Machine-Unique Key (Dynamic Entropy): We tie your encryption key to the unique fingerprint of your specific computer. If the files are stolen and moved to another PC, they cannot be opened.

You can verify that the "Locked Room" is active by checking the Access Control List (ACL) of the data directory. Run the following command in an elevated PowerShell window:

(Get-Acl "C:\ProgramData\Servy").Access | Select-Object IdentityReference, IsInherited, AccessControlType

What to look for in the output:

• IdentityReference: You should only see NT AUTHORITY\SYSTEM and BUILTIN\Administrators.
• IsInherited: This should ideally be False, indicating that the folder has been intentionally isolated from the more permissive ProgramData defaults.
• AccessControlType: This should be Allow for the authorized groups, with no entries for Everyone or Users.

How We Protect Your Data

We have overhauled our security model to be proactive rather than reactive.

1. Automatic Directory Hardening (ACLs)

In previous versions, we relied on Windows defaults for the %ProgramData%\Servy folder. In v7.9+, Servy takes control. Upon installation or startup, the application automatically performs the following actions:

• Breaks Inheritance: We disconnect the folder from the open permissions of the parent drive.
• Explicit Purge: We surgically remove access for the Users, Authenticated Users, and Everyone groups.
• Restricted Entry: Only SYSTEM and Administrators are allowed in. This prevents Local Privilege Escalation: the risk of a standard user tampering with a service to gain Admin rights.
• Downward Inheritance: All subfolders and files within %ProgramData%\Servy automatically inherit these strict parent ACLs, ensuring new service directories, configurations, and logs remain locked down by default.
• Custom Permissions Preserved: While broad, insecure defaults are purged, any explicit, custom ACLs you have manually applied to %ProgramData%\Servy or its subfolders are retained and respected.

2. Machine-Unique Encryption (Dynamic Entropy)

We use the Windows Data Protection API (DPAPI) with an added security layer. To prevent binary analysis (where someone reads our code to find a secret), we derive our encryption entropy from your computer's unique MachineGuid.

• Why it is safe: The combination to the vault is not written in our code; it is hidden in your Windows Registry.
• Non-Portable: Because every computer has a different ID, your aes_key.dat file is useless if copied to another machine.

3. Cryptographic Key Derivation (HKDF)

To adhere to strict cryptographic best practices, we use HKDF (RFC 5869) to derive independent sub-keys from your master key. By combining a cryptographic salt with distinct context strings (V2_AES_ENCRYPTION and V2_HMAC_AUTHENTICATION), we guarantee absolute key separation between our encryption operations and our authentication layers.

4. Authenticated Encryption (v6.5+)

We use AES-256-CBC with HMAC-SHA256. This does not just hide your data; it wraps it in a digital seal. If an attacker tries to modify even a single bit of the encrypted data, Servy will detect the tampering and refuse to decrypt it, preventing bit-flipping attacks.

5. In-Memory Defense (Memory Zeroing)

Security doesn't stop at the hard drive. To protect against advanced memory scraping attacks, Servy securely handles secrets in RAM. Our SecureData class implements IDisposable and utilizes CryptographicOperations.ZeroMemory() to wipe every sensitive buffer as soon as it is no longer needed:

• Transient Data: Plaintext and ciphertext buffers are zeroed immediately after each encryption/decryption call.
• Initialization Material: The master key clone passed during construction is wiped as soon as sub-keys are derived.
• Key Material: All four derived sub-keys are securely zeroed upon the object's disposal.

Unlike standard array clearing methods, this approach ensures that the memory wipe is never elided by the JIT compiler's release optimizations, significantly reducing the window of opportunity for an attacker to extract keying material from a memory dump.

6. Service Account Credentials (SERVY_PASSWORD)

While Servy supports a --password flag for convenience, passing credentials via CLI flags is insecure. Command-line arguments are visible to any user or process able to enumerate the process list (e.g., Get-Process, pslist, or Event Tracing for Windows) and are often recorded in shell history files.

The Preferred Method: Use the SERVY_PASSWORD environment variable. Servy reads this variable transparently at install time, ensuring the secret never touches the process argument string.

PowerShell Example:

# Set the secret in the process-level environment
$env:SERVY_PASSWORD = 'p@ssw0rd_123!'

# Install the service (omit --password or leave it empty)
servy-cli install --name="MySecureService" --path="C:\App\app.exe" --user="DOMAIN\svc_account"

# Clear the variable immediately after use
Remove-Item Env:SERVY_PASSWORD

Supply Chain and Trust

We believe security requires transparency. You should not have to guess if our software is safe.

• Digitally Signed: All executables are signed by SignPath. This proves the code has not been altered since it left our build server.
• SBOM (Software Bill of Materials): We publish a full list of every ingredient used to build Servy in the CycloneDX format.
• Vulnerability Scanning: We use GitHub Dependabot to monitor for holes in our dependencies 24/7.
• Verified Safe: Servy is regularly reviewed by Microsoft Security Intelligence and passes clean scans on VirusTotal.

The Servy Trust Boundary

Servy operates on a Single Trust Boundary model. All services managed by Servy live in the same secure room: %ProgramData%\Servy.

What this means for you

• Shared Influence: If you give a specific service account Write access to the Servy folder, it can technically see the configuration of other services in that same folder.
• Intended Use: Servy is designed for dedicated app servers, CI/CD agents, and workstations.
• Isolation Tip: If you need absolute Zero Trust isolation between two services, they should be run on separate Virtual Machines or in Windows Containers.

Automatic Permissions Table (v7.9+)

Identity	Access Level	Managed By
SYSTEM	Full Control	Servy (Automatic)
Administrators	Full Control	Servy (Automatic)
Custom Service Accounts	Modify	User (Manual)
Standard Users	None	Servy (Automatic)

Note

If you run a service under a custom Service Account, you must manually grant that account Modify rights to %ProgramData%\Servy. Standard users are blocked by default for your protection.

File Locations and Recovery

Your master encryption keys are stored here:

• Key: %ProgramData%\Servy\security\aes_key.dat
• IV: %ProgramData%\Servy\security\aes_iv.dat

The aes_iv.dat file holds the static IV used by the legacy v1 cipher format (Servy < 6.5). Servy 6.5+ uses a per-message random IV that is embedded in the ciphertext, so the static IV is only read when AllowLegacyV1Decryption is explicitly enabled to migrate old data. The file is still created on every fresh install for forward-compatibility - do not delete it.

Critical Warning: Machine Migration

Because our encryption is tied to your specific Windows installation, you cannot simply copy the .dat files to a new server.

To move Servy to a new PC:

1. Export your services on the old machine (the export is unencrypted; treat it like a physical key — Parameters, EnvironmentVariables, etc. are written in plaintext).
2. Move the Export file to the new machine.
3. Import the services. Because Servy never persists the LogOn account/password into the export, the imported services will run as LocalSystem by default.
4. Re-enter the service account credentials manually in Servy Manager (or via servy-cli install) for any service that should not run as LocalSystem.

Step 4 is mandatory if your services run under a domain account, MSA, or local account.

Best Practices

• Backup the Security Folder: Before doing a Windows Reset or Refresh, back up your keys.
• Use Managed Accounts: When possible, run services under Managed Service Accounts (MSA) for the best balance of security and ease of use.
• Audit Access: Periodically check the Security tab of the %ProgramData%\Servy folder to ensure no unauthorized users have been added manually.

Troubleshooting

• Access Denied on Startup: This usually means the account running the service does not have permissions to the %ProgramData%\Servy folder. Refer to the Permissions Table above.
• Decryption Error: This happens if the .dat files were moved from another computer or if the Windows MachineGuid was altered. You will need to re-enter your service passwords in the Manager.

Servy v7.9+ is designed to be invisible but invincible. By automating the routine parts of Windows security, including Access Control Lists and Registry GUIDs, we ensure your infrastructure stays locked down without needing a degree in cryptography.

Questions? Check our full Troubleshooting Guide or join the community discussion.