Badge-Technik

Vom NFC-Scan zum krypto­grafischen Nachweis

21Meetup verbindet einen vor Ort erhaltenen Session-Payload mit Schnorr-Signaturen, Claim-Binding, lokaler Speicherung und einem dezentralen Vertrauensmodell.

Badge über NFC oder QR scannen
Der Teilnehmer scannt vor Ort einen NFC-Tag oder Rolling QR-Code.
Gesamtablauf

Vier Schritte vom Meetup zur Badge-Wallet

Organisator und Teilnehmer besitzen jeweils ein Nostr-Schlüsselpaar. Der Organisator signiert die Meetup-Daten, der Teilnehmer prüft diese und bindet den Nachweis anschließend mit einer eigenen Claim-Signatur an seine Identität.

Session starten

Der Organisator erstellt eine zeitlich begrenzte Meetup-Session. Zu den signierten Daten gehören unter anderem Version, Zeit, Meetup-Kennung, Blockhöhe und eine zusätzliche Session-Kennung.

NFC oder Rolling QR bereitstellen

Die signierten Meetup-Daten werden als kompakter NFC-Payload oder als rotierender QR-Code bereitgestellt.

Signatur und Gültigkeit prüfen

Das Smartphone des Teilnehmers prüft den Payload, die Schnorr-Signatur, das Zeitfenster und die zur Session gehörenden Daten.

Badge an den Teilnehmer binden

Der Teilnehmer erzeugt eine eigene Claim-Signatur. Erst diese zweite Signatur bindet den Badge an genau dieses Nostr-Schlüsselpaar.

ORGANISATOR
Nostr-Keypair
    ↓
Meetup-Daten signieren
    ↓
NFC-Payload oder Rolling QR
    ↓ Scan
TEILNEHMER
Organisator-Signatur prüfen
    ↓
Claim mit eigenem Nostr-Key signieren
    ↓
Badge mit zwei Signaturen lokal speichern
Physischer Trigger

NFC: kompakt, passiv und nur aus kurzer Distanz lesbar

Der Organisator kann einen kompatiblen NFC-Tag mit einem kompakten, signierten Payload beschreiben. Der Tag benötigt keine eigene Stromversorgung und wird vom Smartphone nur aus unmittelbarer Nähe ausgelesen.

Was auf dem Tag liegt

  • signierte Meetup- und Sessiondaten
  • öffentlicher Schlüssel des Organisators
  • kryptografische Signatur
  • keine private Schlüsseldatei und keine Teilnehmerdaten

Warum NFC sinnvoll ist

  • sehr kurze Reichweite
  • kein Akku im Tag erforderlich
  • einfaches Scannen durch Auflegen des Smartphones
  • physischer Kontakt zum Veranstaltungsort
NFC-Tag für eine Meetup-Session beschreiben
Der Organisator beschreibt den NFC-Tag für die laufende Session.
Anti-Replay

Rolling QR: ständig wechselnde Nonce statt statischem Screenshot

Der QR-Code basiert auf einem signierten Grund-Payload und einer sich regelmäßig ändernden Nonce. Dadurch ist ein alter Screenshot nach kurzer Zeit nicht mehr gültig.

Sicherer Session-Seed

Für die Session wird ein kryptografisch sicherer Zufallswert erzeugt und geschützt gespeichert.

Rotierende Nonce

Der QR-Code wird in kurzen Abständen neu erzeugt. Die App akzeptiert nur Nonces aus dem gültigen Zeitfenster.

Identischer Badge

NFC und Rolling QR führen nach erfolgreicher Prüfung zum gleichen Badge-Modell und derselben Beweiskette.

Rolling QR Session in der 21Meetup App
Live-Session mit NFC- und Rolling-QR-Werkzeugen.
BIP-340 Schnorr

Zwei Signaturen mit unterschiedlichen Aufgaben

Die Organisator-Signatur bestätigt, dass der Session-Payload mit dem zugehörigen Organisator-Schlüssel signiert wurde. Die Claim-Signatur des Teilnehmers verhindert, dass ein fremder Badge einfach kopiert und der eigenen Reputation zugerechnet wird.

1. Organisator-Signatur

Der Organisator signiert den kanonisch aufgebauten Inhalt der Meetup-Session mit seinem Nostr-Schlüssel. Der Teilnehmer kann die Signatur mit dem öffentlichen Schlüssel prüfen.

2. Claim-Signatur

Der Teilnehmer signiert den Claim mit seinem eigenen Nostr-Schlüssel. Dadurch wird der Badge an genau diesen Sammler gebunden.

Claim-Binding: Ein gültiger Organisator-Payload allein reicht nicht für die persönliche Reputation. Erst der gebundene Claim erzeugt den vollständigen Nachweis aus „Meetup fand statt“ und „dieses Schlüsselpaar hat den Badge beansprucht“.
Kryptografische Absicherung und Speicherung
Organisator-Signatur, Teilnehmer-Claim und lokale Speicherung.
Defensive Verifikation

Nur erwartete Felder und gültige Formate werden akzeptiert

Vor der Signaturprüfung wird der relevante Inhalt kanonisiert und defensiv validiert. Unbekannte Felder werden bei dieser Prüfung ignoriert und dürfen deshalb nicht als kryptografisch bestätigt behandelt werden.

Whitelist statt Blacklist

Nur die definierten Content-Felder v, t, m, b und x werden für die Verifikation berücksichtigt.

* Diese Kürzel stehen für Version, Zeitstempel, Meetup, Bitcoin-Blockhöhe und einen zusätzlichen Sitzungswert. Weitere Felder können zwar im übertragenen Datensatz stehen, gelten bei dieser Prüfung aber nicht automatisch als signiert oder bestätigt.

Kanonisches JSON

Alphabetisch sortierte Schlüssel sorgen dafür, dass aus denselben Daten derselbe deterministische JSON-Inhalt entsteht.

Längenprüfung

Öffentliche Schlüssel werden auf 64 Hex-Zeichen und Signaturen auf 128 Hex-Zeichen geprüft, bevor die kryptografische Verifikation beginnt.

Badge-Wallet

Die vollständige Sammlung bleibt lokal

Die Badge-Wallet zeigt Meetup, Datum, Blockhöhe und Verifikationsstatus. Die vollständige Teilnahmehistorie wird nicht als öffentliche Liste auf Nostr veröffentlicht.

SchnorrSignatur
ClaimBindung
BlockZeitanker
LokalSpeicherung
Badge-Detail mit Blockhöhe und Verifikationshash
Einzelner Badge mit kryptografischen Details.
Badge-Wallet mit mehreren Badges
Gesammelte und überprüfbare Badges in der Wallet.
Reputation

Ein Score aus Vielfalt, Qualität, Reife und Aktivität

Der Trust Score soll nicht bloß die Anzahl der Badges zählen. Er berücksichtigt Vielfalt, Qualität, Reife und Aktivität. Dahinter steht ein Cost-Prinzip: Anreise, Entfernung, Zeit und wiederholte persönliche Teilnahme machen Badges aufwendig und erschweren künstlich erzeugte Reputation.

Diversity

Verschiedene Meetups, Städte und Organisatoren erhöhen die Aussagekraft des Netzwerks.

Quality

Badges aus besser belegten Meetups mit mehreren verifizierten Teilnehmern erhalten mehr Gewicht.

Maturity

Account-Alter und kontinuierliche Teilnahme bilden langfristiges Engagement ab.

Activity und Verfall

Regelmäßigkeit zählt, wird aber begrenzt. Das Gewicht älterer oder lange nicht ergänzter Aktivität kann mit der Zeit abnehmen, sodass Reputation erhalten werden muss.

Sybil- und KI-Resistenz: Ein Bot oder KI-Profil kann Schlüssel und Online-Inhalte erzeugen, aber nicht selbst zu Meetups anreisen. Das System macht deshalb reale Anwesenheit zu einer knappen Ressource, ohne daraus eine Garantie über Identität oder Vertrauenswürdigkeit abzuleiten.
Wie digitale Reputation entsteht
Reputation basiert auf nachvollziehbarem Aufwand.
Trust Score und Reputation QR
Aggregierter Trust Score als teilbarer QR-Nachweis.
Web of Trust

Organisatoren durch Reputation und gegenseitiges Bürgen

Das Admin-Modell soll ohne dauerhafte zentrale Ernennung auskommen. Organisatoren können füreinander bürgen; Warnungen werden gewichtet und erhalten erst durch mehrere unabhängige Stimmen Wirkung.

Vouching

Signierte Bürgschaften werden über Nostr veröffentlicht und können widerrufen werden.

Distrust-Meldungen

Eine einzelne Warnung ist zunächst nur ein Signal. Mehrere unabhängige Meldungen können zum Downgrade führen.

Bootstrap-Phasen

Mit wachsendem Netzwerk steigen die Anforderungen an Badges, Meetups, Signer und Account-Alter.

Web of Trust mit Bürgschaften und Meldesystem
Vouching, gewichtete Meldungen und Sybil-Resistenz.
Vernetzungsgraph der 21Meetup App
Direkte und indirekte Verbindungen im Vertrauensnetzwerk.
Nostr

Aggregierte Reputation statt öffentlicher Besuchsliste

Die App kann aggregierte Reputationsdaten auf konfigurierbaren Relays veröffentlichen. Dabei werden keine vollständigen Meetup-Namen oder Besuchsdaten benötigt.

Reputations-QR

Der QR enthält aggregierte Kennzahlen und einen kryptografischen Proof-Hash, aber keine komplette private Teilnahmehistorie.

Relay-Publishing

Aggregierte Reputation kann als ersetzbares Nostr-Event veröffentlicht und von anderen geprüft werden.

Schlüssel und Backup

Private Schlüssel bleiben im geschützten Gerätespeicher

Die Android-App nutzt den geschützten Schlüsselspeicher des Betriebssystems. Backups werden verschlüsselt; zusätzliche Geräteprüfungen können auf typische Anzeichen eines kompromittierten Systems hinweisen.

Secure Storage

Private Schlüssel werden über den Android Keystore geschützt und nur für kryptografische Signaturen verwendet.

Verschlüsseltes Backup

Backups werden mit AES-256 verschlüsselt; der Schlüssel wird per PBKDF2 aus dem Nutzerpasswort abgeleitet.

Geräteintegrität

Die Android-App prüft beim Start auf typische Root-Indikatoren wie su-Dateien, Magisk oder auffällige Build-Tags. Bei einem Verdacht erscheint eine Warnung; das Gerät wird nicht automatisch gesperrt.

* Diese Prüfung ist eine zusätzliche Warnschicht und kein sicherer Beweis dafür, dass ein Gerät unverändert oder kompromittiert ist. Entscheidend bleiben die Signaturprüfung und der geschützte Schlüsselspeicher.

Wichtig: Da die vollständige Badge-Sammlung lokal gespeichert wird, sollte regelmäßig ein verschlüsseltes Backup erstellt und sicher verwahrt werden.
Hinweis zu regelmäßigen Backups
Selbstverwahrung bedeutet auch Verantwortung für das Backup.