Last updated: 2026-10-01 · Operator: SparkRelay Tech Services
Purpose. This document describes the encryption and access-control measures implemented by SparkRelay Tech Services to protect the confidentiality, integrity, and availability of data processed by the MultiSigner service. It forms part of the technical and organizational measures referenced in our Data Processing Agreement and Privacy Policy.
1. Purpose and Scope
This document describes the technical controls that SparkRelay Tech Services ("Company," "we," or "us") implements to protect personal data and other information processed by the MultiSigner service (the "Service"). It applies to the Service, its supporting infrastructure, and the personnel who operate it.
2. Data Classification
We classify data according to its sensitivity to apply proportionate controls:
Public: information intended for public disclosure (e.g., these documents);
Internal: operational data not intended for public disclosure;
Confidential: customer account and profile data, uploaded documents, and signing metadata;
Highly sensitive: digital certificates (.p12/.pfx), their passwords, and authentication secrets, which receive the strictest controls and are processed only transiently.
3. Encryption in Transit
All traffic between users and the Service is encrypted using TLS (HTTPS) in production, terminating at an Apache reverse proxy.
Internal traffic between the proxy and the application occurs over the local loopback interface (127.0.0.1).
Outbound connections to third parties (payment providers and Merchants of Record, the email/SMTP provider, any Time Stamping Authority, and any IP geolocation service) are made over TLS/HTTPS.
Session cookies are marked Secure (in production), HttpOnly, and SameSite=Lax.
4. Encryption at Rest
Passwords are stored only as one-way bcrypt hashes (cost factor 10) and are never stored in plain text.
One-time passwords (OTP), signup-verification codes, and password-reset tokens are stored only as SHA-256 hashes.
Digital certificates (.p12/.pfx) uploaded for signing are stored encrypted with AES-256-GCM while a signing job is active, and are permanently deleted when the job ends.
Certificate passwords are stored encrypted with AES-256-GCM and are cleared when the signing job ends.
5. Credential and Secret Protection
Application secrets (JWT_SECRET, APP_SECRET) are required in production, must be at least 32 characters, and are stored in environment configuration outside the web root.
Third-party credentials (payment provider keys, Merchant of Record keys, SMTP credentials, webhook secrets) are stored in environment configuration and never logged or exposed to clients.
Secrets are not hard-coded in source code or committed to version control.
6. Application-Layer Encryption
Digital certificates and their passwords are the most sensitive transient data in the Service. They are encrypted with AES-256-GCM using keys derived from application secrets, are held only for the duration of an active signing job (a configurable time-to-live, by default 20 minutes), and are permanently deleted on job completion, failure, cancellation, or expiry. A background cleanup process also purges any orphaned certificates after the TTL.
7. Key Management
Encryption keys are generated from high-entropy secrets and are not stored alongside the data they protect.
Access to keys and secrets is restricted to authorized personnel and systems on a least-privilege basis.
Keys and secrets are rotated when credentials are suspected of being compromised and as part of operational reviews.
8. Authentication Controls
Users authenticate with email address and password; passwords are verified against bcrypt hashes.
Sessions are maintained with a JSON Web Token (JWT) stored in an HttpOnly cookie, with SameSite=Lax and Secure in production.
High-risk operations (confirming a signing job) require an additional one-time password (OTP) delivered to the user's registered email address.
Password-reset and signup-verification flows use single-use, short-lived tokens (expiring after 15 minutes and a few minutes, respectively), with attempt limits.
Authentication and OTP endpoints are protected by rate limiting.
9. Authorization and Role-Based Access Control
Access is enforced on the principle of least privilege.
Two roles exist: admin (system administrators, without an account) and user (members of a customer account).
Multi-tenant isolation is enforced so that users can access only the data of their own account.
Server-side middleware validates authentication and authorization on every protected request.
Administrative functions (including database administration and SQL console access) are restricted to the admin role and are logged.
10. Network and Infrastructure Access
The application binds to the loopback interface (127.0.0.1) and is not directly exposed to the internet.
An Apache reverse proxy terminates TLS and forwards requests, with upload size limits (LimitRequestBody) and X-Forwarded-* headers.
A host firewall restricts access to essential ports (HTTPS and SSH); the internal application port is closed to the public.
The Service is delivered from automatically load-balanced infrastructure across servers in the United States and Canada.
11. Filesystem Permissions
The data directory (database and files) is stored outside the public web root with restrictive permissions (0700).
Only the application service user can access the database and file directories.
Uploaded and signed documents are stored in protected directories and are subject to automatic deletion after the applicable retention period, which is limited and set by us at our discretion. We do not provide permanent or archival storage.
12. Application Security Controls
Mutating requests (POST/PUT/PATCH/DELETE) require an X-Requested-With: XMLHttpRequest header as an anti-CSRF control (payment webhook endpoints are exempt from this header and are instead verified by their own provider signature).
Security headers are applied via helmet.
Rate limiting is applied to authentication, OTP, and general API endpoints.
Input is validated and output is escaped to mitigate injection and cross-site scripting (XSS) risks.
Upload size limits are enforced (PDFs and certificate files).
13. Logging and Monitoring
Security-relevant events (authentication, administrative actions, database administration) are logged with timestamps.
Database-administration actions are recorded in a dedicated log with restrictive permissions (0600).
Logs do not contain plain-text passwords, OTP values, or certificate passwords.
14. Personnel and Physical Controls
Access to production systems is limited to authorized personnel and protected by unique credentials and least-privilege principles.
Personnel with access to personal data are bound by confidentiality obligations.
Infrastructure is hosted in facilities that provide physical security controls (access restrictions, environmental controls, and redundancy) appropriate to a production service.
15. Review and Updates
These controls are reviewed and updated periodically and upon material changes to the Service, the threat landscape, or applicable legal requirements. Any material reduction in the level of protection will be reflected in updated documentation.
16. Contact
For questions regarding these security measures, please contact: