Legal and compliance

1.1 User identity data

• Data: NFC implant UID (stored as SHA-256 hash), user-assigned name, avatar
• Purpose: user identification and account management
• Legal basis: contract performance
• Recipients: none
• Retention: until account deletion
• Security: UID stored as SHA-256 hash, HTTPS in transit, database encrypted at rest

1.2 Saved credentials

• Data: website URL, username, encrypted password, type (Personal / Professional)
• Purpose: password management and autofill
• Legal basis: contract performance
• Recipients: none. User-initiated sharing between SkinID accounts only.
• Retention: until credential or account deletion
• Security: ChaCha20-Poly1305 AEAD with per-credential keys derived via HKDF-SHA256

1.3 FIDO2 passkeys

• Data: relying party ID, credential ID, encrypted private key, public key, user name, sign-in count
• Purpose: passwordless authentication
• Legal basis: contract performance
• Recipients: public key shared with the relying party during registration
• Retention: until passkey or account deletion
• Security: private keys encrypted with the same chip-bound scheme as saved credentials

1.4 Autofill profile

• Data: name, date of birth, gender, emails, phones, addresses, usernames, company, job title
• Purpose: autofilling registration forms
• Legal basis: contract performance
• Recipients: none. Data injected into forms locally in the browser.
• Retention: until profile or account deletion
• Security: encrypted as a single AEAD blob with a per-user key

1.5 Activity log

• Data: action type, detail text, timestamp
• Purpose: security monitoring
• Legal basis: legitimate interest (security)
• Retention: 12 months

1.6 Trusted devices

• Data: device name, IP address, platform, device ID, timestamps
• Purpose: NFC bridge management
• Legal basis: contract performance
• Retention: until device removal or account deletion

1.7 Authentication tokens

• Data: SHA-256 hash of token, prefix, creation date, last used date
• Purpose: session management
• Security: raw tokens never stored. Only hashes persisted.

Technical and organizational measures

• All credentials and keys encrypted at rest with authenticated encryption and per-user keys
• All communications encrypted in transit (HTTPS with TLS 1.3 and HSTS preload)
• Per-user data isolation at the database level
• CSRF protection and rate limiting
• Operator passwords stored as PBKDF2-HMAC-SHA256 hashes using the OWASP recommended iteration count
• Automated encrypted backups (age, X25519 with ChaCha20-Poly1305, private key held on a separate isolated system)
• Server hosted by Infomaniak, Switzerland
• No third-party analytics, tracking, or data sharing

2.1 Definition

A personal data breach is any security incident that leads to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data.

2.2 Detection

• Unusual server access patterns
• Unexpected database queries or exports
• User reports of unauthorized activity
• Security researcher disclosures
• Monitoring alerts (failed authentication spikes, rate limiting triggers)

2.3 Assessment (within 24 hours)

• What data was affected?
• How many users are affected?
• Is the data encrypted? Was the master key compromised?
• Is the breach ongoing or contained?
• What is the risk to affected users?

2.4 Containment (immediately)

• Revoke all active authentication tokens
• Rotate the master encryption key if compromised
• Block unauthorized access vectors
• Take the server offline if necessary
• Preserve evidence

2.5 Notification to the FDPIC

As soon as possible (within 72 hours) via databreach.edoeb.admin.ch. The notification includes: nature of the breach, data affected, number of users, consequences, and measures taken.

2.6 Notification to affected users

Required if the breach poses a high risk to users. Users are notified via the management panel and any available contact information. The notification explains what happened, what data was affected, what the user should do, and what SkinID has done.

2.7 Post-incident review

Within 2 weeks: document the timeline, identify root cause, implement corrective measures, update procedures.

Contact

FDPIC: www.edoeb.admin.ch
Breach notification: databreach.edoeb.admin.ch

3.1 Description

SkinID is a Swiss authentication platform that uses a subdermal NFC cryptographic implant as a universal identity key. Users scan their hand to authenticate across digital and physical environments.

Data processed

• NFC implant UID (SHA-256 hash)
• Encrypted website credentials (passwords)
• Encrypted FIDO2 private keys
• Encrypted autofill profile (name, contacts, addresses)
• Activity logs, device information, sharing relationships

Data flows

User's implant → NFC reader → SkinID app / extension → HTTPS → SkinID server (Switzerland). No data flows outside Switzerland. No third-party APIs receive user data.

3.2 Necessity and proportionality

Each data category serves a specific functional purpose (authentication, password management, form autofill). No email, phone, or real name is required to use the core service. SkinID collects significantly less personal data than comparable services. Data collection is proportionate.

3.3 Risk assessment

3.4 Mitigation measures

• Authenticated encryption (ChaCha20-Poly1305 AEAD) with per-user keys
• Master key stored separately from the database
• SHA-256 token hashing
• Auto-lock after inactivity
• Per-user data isolation
• Automated encrypted backups
• AES-128 mutual authentication (NXP DESFire EV3) on the chip layer

3.5 Conclusion

The processing is necessary and proportionate. Identified risks are mitigated by technical and organizational measures. Residual risk level: LOW.

This assessment is reviewed annually, when significant changes are made, or after any security incident. A more detailed version of this assessment is available to qualified reviewers and partners on request.