Security Architecture

Security Architecture – Freeck

Last updated: 2025-02-10

This document describes the security model implemented in Freeck/Qreeck.
It covers authentication, QR token security, offline storage, database rules, cryptography, and Firebase integrations.

1. Overview

Freeck/Qreeck is a mobile application built with Flutter.
The backend relies entirely on Firebase services:

Firebase Authentication
Firebase Firestore
Firebase Storage (optional)
Firebase Analytics (technical)
Firebase Crashlytics
Cloud Functions (optional)
Local SQLite for offline mode

2. Security Goals

Prevent impersonation of users
Guarantee integrity of QR tokens
Prevent unauthorized ticket duplication or tampering
Secure locally cached data
Enforce strict access control
Minimize personal data exposure
Ensure confidentiality and transport-layer security

3. Authentication & Session Security

3.1 Firebase Authentication

Email/password or OAuth
Passwords never touch Freeck servers (handled by Firebase)
All communication over HTTPS/TLS 1.2+
Automatic brute-force protection

3.2 Token Refresh

Firebase issues short-lived ID tokens
Automatic token rotation
Session invalidation supported

4. QR Token Security

4.1 No Personal Data in QR Codes

QR payloads must never contain:

name
email
raw user ID

Allowed:

authorization token
ticket ID
event ID
expiration timestamp
signature

4.2 Token Structure

Example (JSON before encoding):

{
  "tid": "ticket123",
  "eid": "event123",
  "n": 2,
  "exp": 1738000000
}

Encoded:

base64url(JSON) + "." + signature

4.3 Signature

HMAC-SHA256 signature (MVP)

signature = HMAC_SHA256(secret_key, payload)

Recommended for production: Asymmetric signature

Private key signs tokens in backend
Public key embedded in mobile app verifies integrity
Prevents secret key extraction

5. Offline Data Security

5.1 SQLite Local Storage

Data stored offline:

pending ticket validations
temporary authorizations
timestamps

Security model:

stored in OS sandbox
no personal data in clear
signed tokens prevent tampering

5.2 Tamper Protection

The app verifies:

signature validity
expiration timestamp
event ID consistency

Invalid or replayed tokens are rejected.

5.3 Automatic Cleanup

Data removed after successful sync
Expired tokens purged automatically

6. Firestore Security

6.1 Firestore Rules enforce:

UID-based access
Role-based permissions (attendee, organizer, cashier, vendor)
Event-level isolation
Validation of fields and IDs

6.2 Example principle (conceptual)

allow read, write: if request.auth.uid != null
                   && resource.data.eventId in getUserEvents(request.auth.uid);

7. Network Security

TLS enforced for all communications
No plain HTTP allowed
Firebase ensures certificate validation

8. Logging & Monitoring

Crashlytics: crash/error logs (no PII)
Analytics: anonymized technical events
No personal data stored in logs

9. Key Management

Secrets stored in Firebase Functions environment variables
Mobile app contains only public keys (if asymmetric crypto is used)
Regular key rotation recommended

10. Future Improvements

Full SQLCipher encryption for offline DB
Certificate pinning in Flutter
Hardware-backed keystore usage (Android/iOS)
Advanced fraud detection (pattern analysis)

11. Security Contact

security@[domain]