Technology & Security

Secure by architecture,
invisible by design.

Knock delivers HIPAA-safe clinical messages inside the tools clinicians already use — iMessage and SMS — with end-to-end encryption and zero PHI ever placed in the text.

End-to-end encrypted HIPAA-aligned Biometric-gated No new inbox

The stack

What Knock is built on

Four layers, each chosen so a secure message can travel from one clinician to another without a new app to learn.

Client

Apps & devices

  • Flutter app (iOS & Android)
  • Swift iMessage extension
  • SwiftUI App Clip
  • Face ID / Touch ID unlock
Delivery

Where messages ride

  • Apple iMessage (MSMessage)
  • SMS via Intelepeer
  • App Clip universal links
  • Secure web portal fallback
Backend

API & logic

  • Laravel 12 (PHP 8.4)
  • REST API + JWT auth
  • Server-side encryption
  • HIPAA-safe AI summaries
Data & infra

Where it lives

  • MySQL on AWS RDS
  • AWS S3 encrypted files
  • Nginx / EC2 · CloudFront
  • Comprehensive audit logs

Architecture

How a message travels

Watch the flow: content is encrypted on the sender's device, relayed through the Knock API, and revealed only to an authenticated recipient — the carrier only ever sees a link.

Sender
Clinician device
Flutter app / iMessage extension encrypts the message locally
Face ID / Touch ID
Unlocks keys before send
Knock API
Laravel API
Stores ciphertext, issues a secure link, routes delivery
MySQL · S3
Encrypted content & attachments at rest
Intelepeer
Sends the App Clip link over SMS
NPI verification
Clinician identity checked live against the CMS NPPES registry (API v2.1)
Delivery
iMessage bubble
“New Message · Knock Encrypted”
SMS + App Clip
Link opens the App Clip / web portal
Recipient
Authenticated view
Biometric unlock → decrypt → read. No PHI in transit.

encrypt on device → ciphertext to API → link over iMessage/SMS → biometric unlock → decrypt & read

Hosting & regions

Where Knock runs

Knock is hosted on Amazon Web Services. Every service that stores or processes PHI lives in a single United States region — us-west-2 (Oregon) — with Amazon CloudFront serving only public static assets from a global edge network.

us-west-2 · Oregon
Compute

The Laravel API runs on Amazon EC2 behind Nginx.

EC2 · Nginx · PHP-FPM 8.4 · Laravel 12
us-west-2 · Oregon
Database

Structured data on managed Amazon RDS (MySQL), encrypted at rest.

RDS · MySQL · encrypted at rest
us-west-2 · Oregon
Object storage

Amazon S3 holds server-encrypted attachments and the static console assets.

S3 · encrypted files + web assets
Global edge
Edge / CDN

Amazon CloudFront serves the public site & web consoles worldwide — origin in us-west-2. No PHI is cached.

CloudFront · PriceClass All · www.knockmessaging.com
CI/CD
Deployment

GitHub Actions deploys over SSH, opening the EC2 security group only for the runner's IP, then revoking it.

Actions → SSH → migrate · just-in-time ingress
External to AWS
Third-party services

Called outbound from the API for auth, delivery and lookups.

Firebase Auth · Sendblue / Intelepeer / Twilio · Apple APNs · CMS NPPES · EMR FHIR

Data residency. All PHI-bearing services — compute, database and storage — run in AWS us-west-2 (United States). CloudFront's global edge caches only public static assets, never protected health information.

Deployment architecture diagram Open full diagram
Knock deployment and hosting architecture: clients, CloudFront edge, AWS us-west-2 region (EC2, RDS, S3) and external services. Open in new tab

Data model

The schema, at a glance

A high-level view of the core entities and how they relate — messaging on one side, the multi-tenant SMS service on the other.

Messaging core
users
id · name · phone · public_key · role
messages
id · sender_id → users · recipient_phone · server_encrypted_content · status
belongs to users · has files
files
id · message_id → messages · s3_key · type · size
SaaS SMS service · Intelepeer APIs
Intelepeer APIs
REST endpoints · send / inbound webhooks · usage & delivery status
authenticated per customer via api_clients
customers
id · name · contact_email · customer_plan_id → plans
has api_clients, users, sms_logs
customer_plans
id · name (Trial / Premium) · monthly_sms_limit
customer_users
id · customer_id → customers · phone · is_spam
sms_logs · inbound_messages
customer_id · recipient/phone · status · direction · created_at
per-customer thread history
api_clients
id · customer_id → customers · key_hash · active

10+ tables · MySQL on AWS RDS · migrations-versioned

Encryption

How Knock is encrypted

Every message is end-to-end encrypted. The plaintext never touches the carrier, the SMS, or an unauthenticated screen — only a link does.

Keys generated on the device

Each user gets an RSA-2048 key pair created on-device. The private key never leaves the phone; only the public key is shared with the server.

RSA-2048 · Keychain / Secure Enclave

Content sealed with AES-256

The message body is encrypted with a one-time AES-256-CBC key, which is then wrapped with the recipient's public key.

AES-256-CBC + RSA-OAEP key wrap

Only a link is delivered

iMessage/SMS carry a secure App Clip link — never PHI. The bubble simply reads “New Message · Knock Encrypted.”

App Clip universal link · zero PHI in transit

Decryption requires the person

The recipient authenticates with Face ID / Touch ID; the message is decrypted on-device. Keys are shared app↔extension via a secure iOS App Group.

Biometric gate · on-device decrypt
Encrypted in transit and at rest. For recipients not yet on Knock, content is server-encrypted at rest and revealed only through an authenticated, biometric-gated session — with certificate pinning, 15-minute session timeouts, screenshot & jailbreak detection, and remote wipe.

Safeguards

Security & compliance

End-to-end encryption
RSA-2048 + AES-256, mandatory on every message.
Biometric authentication
Face ID / Touch ID on every entry point.
15-minute session timeout
App, extension, and portal auto-lock.
Screenshot & jailbreak detection
Blocks capture and compromised devices.
Remote wipe & hard delete
HIPAA-grade secure disposal, cascade-audited.
Comprehensive audit logging
Every access and deletion is recorded.

PHI & HIPAA

How PHI is protected

A plain-language summary of how Knock handles Protected Health Information and the standard practices it follows — written so you can copy it straight into a security review or vendor questionnaire.

PHI & HIPAA handling

Knock is designed to the HIPAA Security Rule. Protected Health Information (PHI) is encrypted end to end, is never placed in a text message, and is disclosed only to an authenticated, biometric-verified recipient.

Technical safeguards

  • End-to-end encryption. RSA-2048 key exchange with AES-256 message encryption. Private keys are generated and stored on the user's device (Secure Enclave / Keychain) and never leave it.
  • Zero PHI in transit. SMS and iMessage carry only a secure link — never clinical content. The mobile carrier never sees PHI.
  • Encryption at rest. Message content and file attachments are server-encrypted with AES-256 in the database and object storage.
  • Access control & authentication. JWT-authenticated APIs, mandatory Face ID / Touch ID, 15-minute session timeouts, and TLS in transit with certificate pinning.
  • Device integrity. Screenshot and jailbreak/root detection; remote wipe and hard delete of local data.
  • Audit controls. Every access, send, and deletion is recorded in tamper-evident audit logs.

Administrative & operational safeguards

  • Provider identity verification. Clinicians are verified against the CMS NPPES NPI registry before they can message.
  • Least privilege. Access is role-scoped, and PHI is excluded from application logs and error reports.
  • Business Associate Agreements. BAAs are in place with infrastructure providers (AWS) and are available to covered-entity customers.
  • Data residency. All PHI-bearing services run in a United States region (AWS us-west-2); no PHI is cached at the CDN edge.

PHI data-handling practices

  • Minimum necessary. Only the data required to deliver a message is processed.
  • Secure disposal. Hard delete with cascade auditing on request.
  • Breach minimization. Because PHI never traverses the carrier or an unauthenticated screen, the messaging channel itself is not an exposure point.