Encrypted Fields Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Pros:

  • Doctrine-Centric Design: Aligns perfectly with Symfony’s Doctrine ORM, reducing integration friction. The attribute-based approach (#[EncryptedField]) mirrors modern PHP/Symfony patterns (e.g., Symfony UX, Doctrine annotations).
  • Granular Encryption: Field-level encryption avoids over-encrypting non-sensitive data, optimizing performance and storage.
  • Key Hierarchy: Per-record keys (encrypted with a master key) follow security best practices (e.g., AWS KMS, NIST SP 800-57).
  • Transparency: Encryption/decryption happens automatically during Doctrine lifecycle events (prePersist, preUpdate, postLoad), hiding complexity from business logic.
  • Audit Trail: Dedicated encryption_key table enables compliance audits (e.g., tracking key usage, rotations).

• Cons:

  • Doctrine Dependency: Locks the stack to Doctrine ORM, excluding Eloquent (Laravel) or raw SQL applications without significant refactoring.
  • Master Key Single Point of Failure: No built-in key revocation or access controls for the master key (requires external tooling like Vault).
  • Performance Trade-offs:
    • Per-record key generation adds overhead to writes.
    • Decryption on every read may impact read-heavy workloads (e.g., dashboards).
  • Schema Changes: Mandatory encryption_key table migration requires coordination with DBAs and CI/CD pipelines.
  • Limited Cipher Flexibility: Defaults to AES-256-GCM (secure) but lacks support for other algorithms (e.g., ChaCha20 for non-OpenSSL environments).

Integration Feasibility

• Symfony:
  • Seamless: Designed for Symfony’s ecosystem (Flex, Doctrine, console commands). Minimal setup beyond composer require and migration.
  • Tooling: Leverages Symfony’s dependency injection for master key configuration and console commands for key rotation.
• Laravel:
  • Challenging: Requires:
    • Doctrine ORM integration (e.g., laravel-doctrine/orm).
    • Manual adaptation of Symfony-specific components (e.g., replacing gebler_encrypted_fields.yaml with Laravel config).
    • Custom console commands to replace Symfony’s make:migration and gebler:encryption:rotate-key.
  • Alternatives: Evaluate Laravel-native packages (e.g., spatie/laravel-encryption) if Doctrine overhead is prohibitive.
• Database:
  • Compatible: Works with any Doctrine-supported database (PostgreSQL, MySQL, SQLite), but performance may vary (e.g., PostgreSQL’s pgcrypto could offer native acceleration).
  • Binary Fields: Supports encrypting binary fields (e.g., BLOBs) but may require tuning for large files.

Technical Risk

• Security Risks:
  • Master Key Exposure: If the master key is leaked (e.g., via .env commits or secrets manager misconfiguration), all per-record keys are compromised.
    • Mitigation: Use a secrets manager (AWS Secrets Manager, HashiCorp Vault) with strict IAM policies. Rotate keys via CI/CD pipelines.
  • Side-Channel Attacks: OpenSSL’s AES-GCM is secure, but custom implementations may introduce vulnerabilities.
    • Mitigation: Audit the bundle’s OpenSSL usage (e.g., constant-time comparisons for key operations).
  • Key Rotation Complexity: The rotate-key command decrypts/re-encrypts all data, which may be disruptive for large datasets.
    • Mitigation: Test rotation in staging; consider incremental rotation for critical systems.
• Operational Risks:
  • Migration Failures: The encryption_key table migration could conflict with existing schemas or CI/CD pipelines.
    • Mitigation: Test migrations in a staging environment; use database transactions.
  • Performance Bottlenecks: Encryption/decryption may slow down high-throughput operations (e.g., bulk inserts).
    • Mitigation: Benchmark with production-like data volumes; cache decrypted values for hot fields.
• Maintenance Risks:
  • Package Maturity: Low star count (6) and infrequent updates (last release: 2025-04-05) may indicate limited long-term support.
    • Mitigation: Fork the repository if critical features are missing; monitor GitHub issues for unresolved bugs.
  • Dependency Updates: OpenSSL and Doctrine version compatibility may require manual intervention.
    • Mitigation: Pin versions in composer.json; test upgrades in staging.

Key Questions

1. Compliance Alignment:
   • Does this meet the organization’s specific compliance requirements (e.g., HIPAA’s addressable implementation specifications, PCI DSS 3.5)?
   • Are there gaps in auditability (e.g., no native logs for key access)?
2. Key Management:
   • How will the master key be stored and rotated? (e.g., AWS Secrets Manager, HashiCorp Vault, or manual .env files?)
   • What’s the process for revoking compromised keys without decrypting all data?
3. Performance:
   • What’s the expected impact on read/write operations? Are there benchmarks for similar workloads?
   • Can decrypted values be cached (e.g., with Symfony’s Cache component) to mitigate overhead?
4. Multi-Tenancy:
   • How will tenant-specific encryption keys be managed? (Current design uses a single master key.)
   • Is there a risk of key collision or leakage across tenants?
5. Disaster Recovery:
   • How will encrypted data be restored if the master key is lost? (No built-in backup mechanism.)
   • What’s the RTO/RPO for encrypted data in a failure scenario?
6. Alternatives:
   • Would native database encryption (e.g., PostgreSQL TDE, MySQL’s AES_ENCRYPT) or application-level encryption (e.g., Laravel’s encrypt) better fit the stack?
   • Are there enterprise-grade alternatives (e.g., AWS KMS, HashiCorp Vault) that offer more features (e.g., HSM integration, fine-grained access controls)?

Integration Approach

Stack Fit

• Symfony:
  • Native Integration:
    • ORM: Fully compatible with Doctrine 2+ (tested with Symfony 5.4+).
    • Configuration: Uses Symfony’s YAML config (gebler_encrypted_fields.yaml) and environment variables for master key storage.
    • Console: Provides Symfony-compatible commands (make:migration, gebler:encryption:rotate-key).
    • Dependency Injection: Master key and cipher settings are injectable via Symfony’s DI container.
  • Recommended Add-ons:
    • Caching: Integrate with Symfony’s Cache component to store decrypted values for frequently accessed fields.
    • Monitoring: Use Symfony’s Profiler to track encryption/decryption latency.
    • Security: Combine with Symfony’s ParameterBag for secure master key handling.
• Laravel:
  • Partial Integration:
    • ORM: Requires laravel-doctrine/orm or spatie/laravel-doctrine (~100–200 LOC to adapt).
    • Configuration: Replace YAML config with Laravel’s .env and a service provider (~50 LOC).
    • Console: Override Symfony commands with Laravel Artisan commands (~150 LOC).
    • Key Management: Use Laravel’s env() helper or a package like vlucas/phpdotenv for master key storage.
  • Alternatives: If Doctrine integration is too cumbersome, consider:
    • Laravel-Specific Packages: spatie/laravel-encryption (simpler but less granular).
    • Database-Level Encryption: PostgreSQL’s pgcrypto or MySQL’s AES_ENCRYPT.
• Other Stacks:
  • Non-Symfony/PHP: Not recommended due to Symfony-specific dependencies (e.g., console commands, Flex recipes).
  • Non-Doctrine ORMs: Requires significant refactoring to adapt the bundle’s lifecycle hooks.

Migration Path

1. Preparation Phase:
   • Audit: Identify sensitive fields in Doctrine entities (e.g., User::creditCardNumber, Patient::ssn).
   • Validation: Verify OpenSSL extension is enabled (php -m | grep openssl).
   • Stakeholder Alignment: Secure buy-in from security/compliance teams for key management processes.
2. Setup:
   • Symfony:

     # Add Flex recipe (optional but recommended)
     composer config extra.symfony.endpoint '[{"url": "https://api.github.com/repos/dwgebler/flex-recipes/contents/index.json"}]'
     composer require dwgebler/encrypted-fields-bundle
     

   • Laravel:

     composer require dwgebler/encrypted-fields-bundle laravel-doctrine/orm
     

   • Generate Master Key:

     php -r "file_put_contents('.env.local', 'ENCRYPTED_FIELDS_KEY='.bin2hex(random_bytes(32)).'\n');"