How We Secure Your Keys and Credentials

When you connect payment providers, electronic invoicing, or other external services, you provide Kanorio with the keys or credentials issued by those services. If these data were exposed, others could potentially collect payments, issue documents, or call services on your behalf. Therefore, Kanorio handles these with an independent storage mechanism rather than storing them alongside general website data.

This page explains the design principles of this mechanism: how keys are encrypted, isolated, accessed, logged, and handled after deletion. For information on which features require keys and where to obtain them, please see the setup instructions for each feature.

Encryption Architecture

Kanorio uses Envelope Encryption, a standard practice in cloud services, to manage the "data encryption keys" and the "master key" that protects them separately:

1. Unique Data Key per Key Set: Every set of keys you provide is encrypted with a randomly generated data key exclusive to that set, using AES-256-GCM.
2. Data Keys Encrypted by the Master Key: Data keys are never stored in plaintext. They are encrypted by the master key before being saved to the database alongside the ciphertext.
3. Master Key Managed by Google Cloud KMS: The master key is not stored on Kanorio's servers, configuration files, or databases, and it cannot be exported. Every time a data key needs to be decrypted, a request must be made to the Key Management Service.
4. Regular Automatic Rotation: The master key is rotated periodically, and existing data is gradually re-protected by the new version.

This layered approach means that even if the database or backups are compromised, no key set can be decrypted without authorization from the Key Management Service.

Site Isolation

Each key set is bound to the specific website and purpose for which it was intended during encryption. If ciphertext is copied to another website or the content is tampered with, integrity verification will fail during decryption, and the system will reject its use. Keys cannot be shared or repurposed between different websites.

Access Control

• Least Privilege: Kanorio's services are granted only the permission to request encryption and decryption from the Key Management Service; they cannot access or export the master key itself.
• Decryption Only at Runtime: Keys are decrypted only at the exact moment the system performs actions like collecting payments, processing refunds, or issuing documents. They are never cached on screens or in logs.
• Masked Display: Once stored, keys are never displayed in full in the dashboard or customer support interfaces. If you need to update them, simply overwrite them with a new set.
• Owner and Admin Access Only: Regular team members cannot view, add, or update keys.

For the few keys generated by Kanorio that you need to set up in your own systems (such as signature keys for verifying notification sources), owners and admins can view them, and every view is logged.

Audit Logs

• Change Logs: Adding, updating, or removing keys records the operator and timestamp (only the credential type and encryption key version are logged; the credential content itself is never recorded).
• Access Logs: Every time the system decrypts a key, the timestamp and purpose are logged.
• Master Key Usage Logs: Every encryption/decryption request made to the Key Management Service is also logged on the Google Cloud side.
• Immutable Logs: All change and access logs are protected by a "write-only" mechanism, ensuring they cannot be modified or deleted, allowing for complete traceability.

These logs record "who, when, and why" and do not contain the key content itself.

Failure Handling and Log Masking

• Fail-Closed, Not Fail-Open: If the Key Management Service is temporarily unavailable, the system stops accessing keys and reports an error rather than falling back to a weaker security posture.
• Automatic Log Masking: Error messages generated by the system contain only fixed error codes. All data sent to server logs and error monitoring systems is automatically scanned to mask fields suspected of being keys, tokens, or credentials, ensuring they are not leaked through third-party service providers.

Deletion and Data Retention

• When you remove a service or delete a website, the associated keys are deleted from the system.
• Database backups are automatically purged according to retention policies, with a maximum retention of 90 days. Keys within backups remain encrypted.
• Some services have additional restrictions before removal—for example, previously issued documents may still require the credentials for future processing. Please refer to the specific feature documentation.

Your Responsibility

Kanorio is responsible for securing the keys you provide; the issuance, revocation, and scope of the keys themselves are managed by the service provider that issued them. We recommend that you:

1. Enter keys only in the Kanorio dashboard settings page. Do not send them via customer support chats, email, or social media.
2. Kanorio support will never ask you for your keys. If someone claiming to be Kanorio asks for them, do not provide them and .
3. If you suspect a key has been leaked, revoke and regenerate it in the service provider's dashboard first, then update it in Kanorio.
4. When a member leaves your team, remove their access in "Site Settings" → "Team" and consider rotating your keys.

Related Documentation