grapheneos/attestationserver

attestation.app remote attestation server. Server code for use with the Auditor app: https://github.com/GrapheneOS/Auditor. It provides two services: submission of attestation data samples and a remote attestation implementation with email alerts to go along with the local implementation based on QR code scanning in the app.

attestationserver's Issues

make challenge index per account

NULL pointer dereference in sqlite4java

Can't seem to get passed SIGSEGV (0xb) at pc=0x000000000000d7c6, pid=30, tid=31

I probably did do something wrong with the database. But I am not sure how to setup the configuration. Or possibly compiled with a wrong OpenJDK ( i am using 12)

This is what I did:

sqlite3 attestation.db "CREATE TABLE Configuration(key, value)"
sqlite3 attestation.db "INSERT INTO Configuration VALUES ('emailUsername', '$EMAIL_USERNAME'), ('emailPassword', '$EMAIL_PASSWORD'), ('emailHost', '$EMAIL_HOST'), ('emailPort', '$EMAIL_PORT')"

This is the stacktrace:

Current thread (0x0000555b2c459000):  JavaThread "main" [_thread_in_native, id=31, stack(0x00007fd5d3c25000,0x00007fd5d3d25ab0)]

Stack: [0x00007fd5d3c25000,0x00007fd5d3d25ab0],  sp=0x00007fd5d3d246f8,  free space=1021k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x000000000000d7c6
C  [libsqlite4java-linux-amd64-1.0.392.so+0x4ee50]  pager_write+0x370
C  [libsqlite4java-linux-amd64-1.0.392.so+0x68fcd]  sqlite3BtreeSetVersion+0x9d
C  [libsqlite4java-linux-amd64-1.0.392.so+0x773e2]  sqlite3VdbeExec+0x9142
C  [libsqlite4java-linux-amd64-1.0.392.so+0x78741]  sqlite3_step+0x2f1
C  [libsqlite4java-linux-amd64-1.0.392.so+0x7cf87]  sqlite3_exec+0xd7
C  [libsqlite4java-linux-amd64-1.0.392.so+0xa271f]  Java_com_almworks_sqlite4java__1SQLiteManualJNI_sqlite3_1exec+0x8f
j  com.almworks.sqlite4java._SQLiteManualJNI.sqlite3_exec(JLjava/lang/String;[Ljava/lang/String;)I+0
j  com.almworks.sqlite4java._SQLiteManual.sqlite3_exec(Lcom/almworks/sqlite4java/SWIGTYPE_p_sqlite3;Ljava/lang/String;[Ljava/lang/String;)I+32
j  com.almworks.sqlite4java.SQLiteConnection.exec(Ljava/lang/String;)Lcom/almworks/sqlite4java/SQLiteConnection;+86
j  app.attestation.server.AttestationServer.open(Lcom/almworks/sqlite4java/SQLiteConnection;Z)V+35
j  app.attestation.server.AttestationServer.main([Ljava/lang/String;)V+13
v  ~StubRoutines::call_stub
V  [libjvm.so+0x853bf2]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x3c2
V  [libjvm.so+0x8cd649]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) [clone .isra.68] [clone .constprop.221]+0x2a9
V  [libjvm.so+0x8cfa84]  jni_CallStaticVoidMethod+0x164
C  [libjli.so+0x4c4e]  JavaMain+0x9ce

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.almworks.sqlite4java._SQLiteManualJNI.sqlite3_exec(JLjava/lang/String;[Ljava/lang/String;)I+0
j  com.almworks.sqlite4java._SQLiteManual.sqlite3_exec(Lcom/almworks/sqlite4java/SWIGTYPE_p_sqlite3;Ljava/lang/String;[Ljava/lang/String;)I+32
j  com.almworks.sqlite4java.SQLiteConnection.exec(Ljava/lang/String;)Lcom/almworks/sqlite4java/SQLiteConnection;+86
j  app.attestation.server.AttestationServer.open(Lcom/almworks/sqlite4java/SQLiteConnection;Z)V+35
j  app.attestation.server.AttestationServer.main([Ljava/lang/String;)V+13
v  ~StubRoutines::call_stub

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000d7c6

replace challenge GET API with a POST API

add email support / verification

port certificate chain pinning from the local verification implementation in the app

split attestation user from the service user

start work on implementing pinning, maybe without certificate chain pinning to start

explain the public demo account

add configuration option for frequency of attestation failure emails

In the user interface it is possible to set both the attestation time period check (4 hours) and the amount of time without an attestation that can pass before a failure alert is sent (48 hours).

I had my handset off for two days and started receiving attestation failure e-mails every 15 minutes. It would be nice if that was configurable.

consider either replacing or reviving sqlite4java since it's poorly maintained

It's a pain even just to build it with an up-to-date sqlite3 with security patches and it lacks basic conveniences like support for try-with-resources.

support saving arbitrary length certificate chains for attestations

implement devices.json for non-demo accounts

switch to a structured JSON API for retrieving device data and formatting in the frontend

add verifiedBootHash display per the app

App issue: GrapheneOS/Auditor#41.

harden against trivial denial of service issues

resolve issue of mail delivery failure notifications going to spam

These are using the FQDN which may be the cause of this.

consider adding a database connection pool

It might not be a good idea to have all these short-lived connections, especially with the way WAL is intended to work. There's currently no need to use more than SQLite and it makes development much easier, but it should probably use it more efficiently.

support changing username

The userId is already the primary key with the username only used for authentication so it will be easy to change.

connect devices to accounts

add support for pinning key of the mail server

add a description of the service with a link to documentation

expose subscribeKey rotation option

add support for multiple alert email addresses

The database supports it, but the UI and API need to be adapted to support it. There should be a limit on the number of email addresses permitted.

generate account qr code dynamically

add a hard limit on sending alerts for a given problem

There is already heavy throttling, but there should also be a hard limit on the number of times people will be contacted about a given problem.

support detecting rollback resistance for key attestation v3 (Pixel 3) per the app

App issue: GrapheneOS/Auditor#40.

throttle alerts

The last time an alert was sent for a device not providing attestations in time should be recorded and used to throttle the alerts. New devices with failures should still send out alerts immediately, and they might as well still include the full list of applicable devices.

implement local database backups

The local backups can then be remotely backed up.

choose a sane rate for database backups

add remaining OS enforced fields to device 'pinning' data

add some more limits to the sample service

add boot / vendor patch level support per the app

stop sending subscribe key via the URL

This could either go in the body before the attestation or in a header.

add email-based alerts

implement basic stateless verification without either challenges or pinning to start

update subscribeKey if it changes just in case it's needed later

move to an actively maintained SQLite library like sqlite-jdbc

https://github.com/xerial/sqlite-jdbc

allow rotating subscribe key

allow paired attestations without submitting subscribe key again

add optional email-based password recovery

add support for the new attestation root certificate

https://developer.android.com/training/articles/security-key-attestation#root_certificate

store and send attestation history as structured data

support 2-factor authentication

log failed attestations as long as they can be accurately attributed to a device

support changing password

add support for deleting devices

support deleting accounts

tune alert delay restrictions based on job scheduler latency

add real accounts

send alert emails