Sentinel Pro Security, Cryptography, and Privacy

>

Security and Privacy Whitepaper (v4.3 Beta / v4.3b1-pro)

Date: 2026-04-01 Applies to bridge runtime and app client model

1. Security Objectives

Sentinel v4.3 beta security is engineered around three outcomes:

1. Protect homeowner authority and access control.
2. Reduce risk from credential misuse and transport interception.
3. Preserve operational accountability through structured audit trails.

2. Threat Model Summary

2.1 High-Priority Threats

• Unauthorized API access with stolen credentials or stale sessions
• Integrator overreach after homeowner revocation or temporary disable intent
• MITM risk when TLS trust is weakly configured
• Abuse of host tools without confirmation gates
• Undetected privileged changes without event logging

2.2 Assumptions

• Host filesystem controls are managed by Savant deployment practices
• LAN/VPN transport may be hostile without TLS hardening
• Client devices can be compromised; server-side guards remain required

3. Cryptography Profile

3.1 Password Storage

Sentinel stores password hashes, never plaintext.

• KDF: PBKDF2-HMAC-SHA256
• Current iterations: 210000
• Legacy compatibility iterations: 20000
• Salt: per-user random salt (SecureRandom.hex(16))

Impact:

• Slower offline brute-force compared to unsalted hashes
• Backward compatibility for older stored credentials

3.2 Session Token Generation

• Token source: cryptographic RNG (SecureRandom.hex(24))
• Session expiry window: 28,800 seconds
• Session metadata carries gate flags used for policy enforcement

3.3 TLS Identity

When use_https is enabled:

• bridge serves HTTPS with configured or generated key/cert material
• SHA-256 fingerprint is exposed in API payloads
• clients can pin expected fingerprint per home

Recommended production posture:

• HTTPS required
• explicit fingerprint pinning in app home profile

4. Access-Control Architecture

4.1 Role Model

Roles:

• integrator
• home_admin
• home_user

Singleton policy:

• only one integrator and one home admin role per installation

4.2 Permission Dimensions

Permissions are normalized by dimension:

• services
• devices
• states
• actions

Each dimension supports:

• mode (all or selected)
• allow
• deny

4.3 Policy Gates

Sentinel requires multiple governance gates before sensitive actions:

• password-change gate
• role-acknowledgment gate
• monitoring-acknowledgment gate
• pairing-complete gate for operational endpoints

4.4 Homeowner Governance Controls

Two homeowner controls are central:

• Permanent revoke:

- endpoint: /api/v1/home/revoke-integrator - effect: integrator remains blocked until new Blueprint config revision or reset flag cycle

• Temporary disable:

- endpoint: /api/v1/home/integrator-access - effect: existing integrator sessions are closed immediately

5. Authentication and Session Security

5.1 Login Blocking Conditions

Integrator login can be denied due to policy flags:

• integrator_access_revoked
• integrator_access_temporarily_disabled

Home admin access can be blocked when reset-required policy is active.

5.2 Session Validation

Each authenticated request enforces:

• token existence and unexpired session
• role/action allow checks
• gate fulfillment checks where required

5.3 Session Hygiene

• expired sessions are purged
• temporary disable action closes active integrator sessions
• role and acknowledgment updates refresh session policy fields

6. Controlled Host Tool Security

6.1 Terminal Tool Controls

Sentinel terminal model reduces blast radius through:

• explicit open/run/close session boundaries
• actor-bound terminal sessions
• command deny filters against high-risk destructive commands
• execution timeout behavior
• per-run audit events

6.2 Reboot Tool Controls

Reboot endpoint requires:

• role-gated access
• explicit two-step confirmation fields
• sudo password

This prevents accidental single-click reboot paths.

6.3 Doorbell Audio Controls

Doorbell update flow includes:

• strict upload size guardrails
• compatibility validation against active reference audio profile
• backup creation before in-place replacement
• clear warning/recovery signaling when live reload fails

7. Audit and Accountability

7.1 Audit Model

Audit records are stored as JSONL and include:

• timestamp
• event type
• actor
• event-specific details

Examples:

• auth success/failure
• role/monitoring acknowledgments
• user create/update/delete
• terminal and reboot actions
• integrator revoke/temporary enable/disable

7.2 Retention

• retention target: 90 days
• periodic prune task removes entries outside policy window

7.3 Audit Visibility Controls

Audit responses are role-filtered:

• /api/v1/audit general scoped access
• /api/v1/admin/audit privileged integrator/home_admin access

8. Privacy Design

8.1 Homeowner-Centric Privacy Principles

1. Owner authority: homeowner can gate/revoke integrator capabilities.
2. Data minimization: API exposes curated data, not unlimited host internals.
3. Locality-first: operational data remains host/app local by default.
4. Transparency: key actions are auditable and reviewable.
5. Revocability: temporary and permanent controls are first-class.

8.2 Data Classes and Sensitivity

Primary data classes:

• telemetry state paths and values
• user identities and roles
• password hashes and salts
• access policy and monitoring profile
• audit events

Sensitive handling notes:

• password hashes are non-reversible but still sensitive
• audit logs may contain operationally sensitive event details
• TLS keys/certs must be host-protected by filesystem controls

8.3 Data Residency and Transfer

• Bridge runtime data is host-local.
• App receives filtered API payloads over LAN/VPN.
• No mandatory external cloud relay for bridge telemetry path.

9. Residual Risks and Hardening Roadmap

9.1 Residual Risks

• non-pinned TLS deployments reduce trust strength
• compromised trusted endpoint can still issue valid requests until token expiry
• local file protections remain essential for confidentiality at rest

9.2 Recommended Hardening Next Steps

1. Enforce HTTPS and certificate onboarding by default in setup UX.
2. Add explicit certificate rotation workflow with user-visible trust prompts.
3. Add endpoint-level rate limits for auth-sensitive routes.
4. Add optional encrypted-at-rest store for policy/user/audit files.
5. Expand security telemetry around repeated failed logins.

10. Security Validation Matrix (v4.3 Beta)

Minimum validation set:

1. Verify password policy and weak-password rejection behavior.
2. Verify session expiry and invalid token handling across endpoint groups.
3. Verify temporary disable closes integrator sessions immediately.
4. Verify permanent revoke blocks future integrator logins.
5. Verify acknowledgment gates block protected actions as expected.
6. Verify audit event generation for all privileged operations.
7. Verify TLS-enabled mode and fingerprint exposure consistency.

11. Conclusion

Sentinel v4.3 beta provides a practical and production-oriented security model for Savant home operations. It combines:

• modern credential storage
• role and policy gate enforcement
• homeowner-governed access controls
• auditable, controlled privileged operations

This architecture is ready for broader beta validation while keeping security and privacy aligned with homeowner trust expectations.