Privacy-First Homestead Security System

Functional Requirements Document (FRD)

Version: 1.1 Status: Engineering Specification Primary Controller: Raspberry Pi Security Controller System Purpose: Privacy-first physical and digital security for a private homestead/server environment

1. Purpose

The Privacy-First Homestead Security System provides a physically controlled security boundary between the occupants, their private computing infrastructure, and unauthorized access.

The system combines:

Physical authentication keys

NFC authentication

Raspberry Pi security controller

Network segmentation

Encrypted storage

Service isolation

Emergency lockdown

Hardware-backed identity

Independent recovery mechanisms

Auditable administrative controls

The design prioritizes privacy, recoverability, least privilege, and deliberate physical authorization.

2. Design Principles

Physical authorization matters.

No single ordinary credential should control the entire system.

Emergency lockdown should be fast and reversible.

Critical administrative capabilities should require separate physical authorization.

Encryption should protect sensitive information at rest.

Network segmentation should limit compromise.

The security controller should have narrowly scoped privileges.

Recovery must remain possible after accidental activation or hardware failure.

Security functions should fail safely rather than catastrophically.

Destructive administrative operations must be separated from emergency response.

3. High-Level Architecture

┌──────────────────────┐

│ PHYSICAL SECURITY │

│ PANEL │

└──────────┬───────────┘

│

┌──────────────────────┼──────────────────────┐

│ │ │

▼ ▼ ▼

NORMAL KEYS E-STOP NFC CREDENTIAL

AUTHORIZATION DANGER MODE MAX LOCKDOWN

│ │ │

└──────────────────────┼──────────────────────┘

▼

┌──────────────────────┐

│ Raspberry Pi Security│

│ Controller │

└──────────┬───────────┘

│

┌────────────────────┼────────────────────┐

▼ ▼ ▼

NETWORK CONTROL SERVICE CONTROL KEY CONTROL

│ │ │

▼ ▼ ▼

VLAN FIREWALLS Vault Locking Credential

VPN CONTROL Session Revocation Revocation

│ │ │

└────────────────────┼────────────────────┘

▼

┌──────────────────────┐

│ Private Server / NAS │

│ Encrypted Storage │

│ CYN-X Infrastructure │

└──────────────────────┘

SEPARATE PHYSICAL RECOVERY KEY

│

▼

CATASTROPHIC ADMIN

AUTHORIZATION

4. Security States

The system shall implement four primary operational states.

4.1 NORMAL

Normal operation.

Permitted:

Authorized users

Normal server access

CYN-X operation

Network services

Approved remote VPN access

Normal storage access

4.2 WARNING

Elevated security state.

Possible actions:

Increase logging

Require reauthentication

Restrict administrative access

Disable unnecessary external services

Increase physical monitoring

Notify authorized administrators

No data destruction occurs.

4.3 DANGER

Emergency physical-security state.

Activated by the physical E-stop.

The system shall:

Immediately restrict network access

Revoke active remote sessions where technically possible

Stop designated sensitive services

Lock or unmount designated encrypted storage where safely possible

Disable unnecessary external connectivity

Restrict administrative interfaces

Preserve system integrity

Maintain recovery capability

DANGER mode shall not irreversibly destroy data.

4.4 MAXIMUM LOCKDOWN

Highest emergency privacy state.

Activated by an authenticated emergency NFC credential.

The system shall:

Isolate sensitive VLANs

Revoke active sessions

Lock designated encrypted volumes

Stop designated sensitive services

Disable remote administrative access

Restrict management interfaces

Rotate or revoke temporary credentials where appropriate

Preserve audit information required for system recovery

Require explicit recovery authorization before returning to NORMAL

MAXIMUM LOCKDOWN shall preserve data integrity.

5. Physical Security-Key Architecture

The system shall use physically separated credentials with different privileges.

5.1 Key Class A — Normal Administration Keys

Purpose:

Routine system administration.

Capabilities may include:

Authenticate administrators

Access approved management interfaces

Start/stop ordinary services

Perform maintenance

Access non-critical configuration

These keys shall not independently authorize catastrophic administrative operations.

5.2 Key Class B — Emergency Recovery Key

Purpose:

Recover the system from emergency states.

Capabilities:

Authorize recovery from DANGER

Authorize recovery from MAXIMUM LOCKDOWN

Restore designated services

Re-enable management access

Validate system integrity

Perform emergency maintenance

The recovery key shall be physically stored separately from ordinary authentication keys.

6. Key Class C — Catastrophic Administrative Key

A dedicated physical security key shall exist for high-consequence administrative operations.

This key shall:

Be physically separate from ordinary keys

Require deliberate physical insertion/presence

Never be required for ordinary system operation

Never be automatically triggered by NFC

Never be exposed through a normal web interface

Require additional authorization safeguards

Be stored securely when not in use

The existence of this key creates a deliberate physical boundary around high-consequence operations.

C-001 — Separate Credential

The catastrophic administrative credential shall be cryptographically distinct from all normal and emergency credentials.

C-002 — Physical Presence

The operation shall require physical presence of the dedicated credential.

C-003 — No Remote Equivalent

The system shall not provide an equivalent remote command capable of substituting for the physical catastrophic-administration credential.

C-004 — Deliberate Authorization

High-consequence operations shall require explicit administrative authorization and shall not be triggered merely by detecting:

Police presence

An E-stop

An ordinary NFC tag

Loss of network connectivity

Loss of power

Failed authentication

Physical tampering

C-005 — Safety Interlock

The system should provide safeguards against accidental activation, including appropriate confirmation/interlock mechanisms.

C-006 — Recovery Separation

Recovery credentials shall remain independent from the catastrophic administrative credential.

7. NFC Architecture

NFC shall use cryptographic authentication rather than trusting an NFC identifier alone.

NFC Requirements

The system shall:

Authenticate the credential cryptographically

Reject unknown credentials

Support credential revocation

Prevent simple identifier cloning

Log authentication events

Rate-limit repeated failures

Require appropriate authorization for privileged actions

Emergency NFC

The emergency NFC credential may activate:

MAXIMUM LOCKDOWN

It shall not directly activate irreversible data destruction.

8. Raspberry Pi Security Controller

The Raspberry Pi shall function as a dedicated security-policy controller.

Responsibilities:

Physical input processing

Authentication

State-machine management

VLAN/firewall control

Service-control orchestration

Credential validation

Emergency-state management

Audit logging

Recovery coordination

The controller shall operate with least privilege.

It shall not possess unrestricted access to every server resource merely because it controls the security system.

9. Hardware Identity

The controller shall have a hardware-backed or otherwise strongly protected identity where practical.

Requirements:

Unique controller identity

Protected private credentials

Secure administrative authentication

Controller replacement/recovery procedure

Ability to revoke a compromised controller

A copied SD card or copied configuration should not automatically become a trusted security controller.

10. Network Architecture

Recommended VLAN structure:

VLAN 10 HOME

VLAN 20 SERVERS

VLAN 30 SECURITY

VLAN 40 MANAGEMENT

VLAN 50 GUEST

VLAN 60 LAB / DEVELOPMENT

VLAN 70 CAMERAS / IOT

Default policy:

VLAN → VLAN

DENY BY DEFAULT

Only explicitly required traffic should be permitted.

The security controller shall have narrowly defined access to the management plane.

Remote administration should use a VPN rather than exposing administrative services directly to the Internet.

UPnP should be disabled where practical.

11. Server Security

Servers should use:

Full-disk encryption where practical

Encrypted sensitive volumes

Strong authentication

Hardware-backed authentication where available

SSH keys/FIDO2-compatible authentication where appropriate

Host firewalls

Minimal exposed services

Automatic security updates where appropriate

Offline or otherwise independently protected backups

Sensitive storage should be capable of being locked or unmounted during emergency lockdown.

12. Cryptography

The system should use established modern cryptographic primitives rather than proprietary encryption.

Potential technologies include:

AES-256 or equivalent authenticated encryption

Argon2id for password-derived keys

TLS 1.3

FIDO2

PIV-compatible credentials

Hardware-backed key storage

“Military grade” shall not be treated as a technical security requirement.

The actual requirement is well-reviewed, appropriately configured cryptography with sound key management.

13. Key Separation

The following functions shall use separate authorization domains:

Normal Administration

│

├── Normal Authentication Key

│

▼

Emergency Lockdown

│

├── E-Stop

└── Emergency NFC

│

▼

Emergency Recovery

│

└── Recovery Key

│

▼

High-Consequence Administration

│

└── Dedicated Catastrophic Admin Key

No ordinary credential shall automatically inherit all privileges.

14. E-Stop Requirements

The physical E-stop shall function as a security-state transition rather than a destructive computer command.

When activated:

Physical input is detected.

Controller verifies the transition.

System enters DANGER.

Network restrictions are applied.

Sensitive services are stopped.

Sensitive encrypted storage is locked/unmounted where safe.

Active sessions are revoked where possible.

System records the security-state transition.

Recovery remains possible.

The E-stop shall not perform irreversible data destruction.

15. Physical Tamper Detection

The system may monitor:

Security-panel opening

Controller enclosure opening

Unexpected key insertion

Repeated authentication failures

Unauthorized configuration changes

Network topology changes

Controller replacement

Tamper detection should cause an appropriate security-state transition rather than automatically destroying information.

16. Power Architecture

The security controller should use UPS-backed power.

Requirements:

Graceful shutdown

Power-loss detection

Emergency-state persistence

Recovery after power restoration

Protection against filesystem corruption

The security controller should not interpret ordinary power loss as authorization for destructive operations.

17. CYN-X Integration

CYN-X may integrate with the security system through a narrow API.

CYN-X may request:

Current security state

Non-sensitive status

Authorized service status

Security notifications

CYN-X shall not independently possess unrestricted authority over the security controller.

High-consequence security actions shall remain under dedicated authorization controls.

18. State Machine

┌───────────┐

│ NORMAL │

└─────┬─────┘

│

security event

│

▼

┌───────────┐

│ WARNING │

└─────┬─────┘

│

E-STOP

│

▼

┌───────────┐

│ DANGER │

└─────┬─────┘

│

Emergency NFC

│

▼

┌──────────────────┐

│ MAXIMUM LOCKDOWN │

└────────┬─────────┘

│

Recovery Key

│

▼

┌───────────┐

│ RECOVERY │

└─────┬─────┘

│

integrity check

│

▼

┌────────┐

│ NORMAL │

└────────┘

The catastrophic administrative key exists outside the ordinary emergency state machine and is reserved for separately authorized high-consequence administration.

19. Audit Logging

The system shall log security-relevant events such as:

Authentication attempts

Successful authentication

Credential revocation

E-stop activation

NFC lockdown activation

State transitions

Recovery authorization

Configuration changes

Controller replacement

Tamper events

Logs should be protected against ordinary modification.

Logging shall not prevent legitimate emergency recovery.

20. Backup Architecture

At least one independent recovery mechanism should exist outside the primary security controller.

Recommended architecture:

PRIMARY SYSTEM

│

├── Encrypted Server Storage

│

├── Local Backup

│

└── Independent Recovery Backup

│

└── Separate Physical Location

The backup system should not depend exclusively on the Raspberry Pi.

21. Functional Requirements

22. Acceptance Testing

Test A — Normal Key

Action: Insert valid normal security key.

Expected:

Authentication succeeds.

Authorized administrative functions become available.

Catastrophic functions remain unavailable.

Test B — Invalid Key

Action: Present unknown credential.

Expected:

Authentication fails.

No privileged operation occurs.

Event is logged.

Test C — E-Stop

Action: Activate physical E-stop.

Expected:

DANGER mode activates.

Sensitive services are restricted.

Sensitive storage is locked/unmounted where safe.

Network access is restricted.

Recovery remains possible.

Test D — Emergency NFC

Action: Present valid emergency NFC credential.

Expected:

MAXIMUM LOCKDOWN activates.

Active sessions are restricted/revoked.

Sensitive services are stopped.

Sensitive encrypted storage is locked where safe.

Recovery remains possible.

Test E — Recovery

Action: Present authorized recovery credential.

Expected:

Recovery workflow begins.

System validates required conditions.

Services can be restored.

System returns to NORMAL only after successful recovery.

Test F — Catastrophic Administrative Credential

Action: Present dedicated catastrophic-admin credential under an authorized maintenance procedure.

Expected:

High-consequence administrative authorization becomes available only after required safeguards.

Ordinary users and remote sessions cannot substitute for the physical credential.

The system records the authorization event.

23. Security Testing

Testing shall include:

Credential cloning resistance

NFC replay resistance

Authentication brute-force resistance

VLAN escape testing

Firewall testing

Privilege-escalation testing

Controller compromise analysis

Physical tamper testing

Recovery testing

Backup restoration testing

Power-loss testing

Secure boot/integrity testing where supported

Key-revocation testing

24. Threat Model

The system shall consider:

Network attacker

Controls a compromised device on the home network.

Defense: VLAN isolation, host firewalls, least privilege.

Stolen credential

An authentication key is lost or stolen.

Defense: credential revocation and separate privilege tiers.

Compromised controller

The Raspberry Pi itself is compromised.

Defense: hardware identity, minimal privileges, network segmentation, independent recovery.

Physical attacker

An unauthorized person gains physical access.

Defense: enclosure protection, physical authentication, tamper detection, encryption, network isolation.

Accidental activation

An authorized person accidentally activates an emergency control.

Defense: recoverable security states, interlocks, separated credentials, independent recovery.

25. Recovery Philosophy

The system shall follow:

Lock first. Recover deliberately. Destroy nothing accidentally.

Emergency controls are intended to rapidly reduce exposure while maintaining the ability to recover the system.

High-consequence administrative operations are intentionally separated from emergency controls so that an emergency button, NFC credential, software bug, or compromised device cannot trivially cause irreversible loss.

26. Final Architecture

HOMESTEAD

│

┌──────────┴──────────┐

│ Physical Security │

│ Panel │

└──────────┬──────────┘

│

┌─────────────────┼──────────────────┐

│ │ │

▼ ▼ ▼

NORMAL KEY E-STOP EMERGENCY NFC

│ │ │

│ ▼ ▼

│ DANGER MAXIMUM LOCKDOWN

│

▼

NORMAL ADMIN

│

└─────────────────┐

▼

┌───────────────────┐

│ Raspberry Pi │

│ Security Controller│

└─────────┬─────────┘

│

┌─────────────┼─────────────┐

▼ ▼ ▼

FIREWALL SERVICES STORAGE

│ │ │

└─────────────┼─────────────┘

▼

PRIVATE SERVERS

│

┌────┴────┐

│ CYN-X │

│ AI │

└─────────┘

SEPARATE PHYSICAL RECOVERY DOMAIN

RECOVERY KEY

│

▼

SYSTEM RECOVERY

SEPARATE HIGH-CONSEQUENCE DOMAIN

CATASTROPHIC ADMIN KEY

│

▼

AUTHORIZED HIGH-CONSEQUENCE

ADMINISTRATION

27. Core Security Rule

The final architecture is governed by four independent principles:

Normal keys authorize normal access.

E-stop creates DANGER mode.

Emergency NFC creates MAXIMUM LOCKDOWN.

The dedicated physical catastrophic-admin key is required for separately authorized high-consequence administration.

The emergency system remains recoverable by design.