| Age | Commit message (Collapse) | Author |
|---|
|
The key creation is handed off to the platform implementation. Windows
will show its own Windows Security UI. On Unix, the application itself
provides the PIN directly, enforcing a minimum of six characters.
|
|
Hardware keys are created and managed exclusively in the protected
environment of the Trusted Platform Module (TPM 2.0), a separate, secure
processor isolated from the rest of the system. Keyring provides them as
an alternative to established software keys for challenge-response
authentication.
Software keys, while far more secure than naive passwords, have their
limitations. They're stored in a keyring file in an encrypted form and
can be extracted and copied. As a result, it's possible to perform
unlimited attempts to decrypt them offline. To mitigate such attacks, a
memory-hard key derivation function must be used to derive the
decryption key, and the passhprase itself must still be sufficiently
strong because a small search space will definitely be exhausted. A side
effect of this is a massive latency spike and potentially disruptive
peak memory usage.
Hardware keys, by design, are non-exportable. Total system compromise
won't lead to key exfiltration due to TPM having no such functionality,
and TPM's tamper resistance makes extraction of secrets infeasible even
with physical access to the machine (if the TPM is genuine).
PIN that is used to protect hardware keys is validated by the TPM
itself, which also locks itself out after too many failed attempts. This
lockout cannot be overridden without either issuing a lockout clear
command with authorization value or resetting the TPM outright, erasing
all keys stored in it. Because of this, low-entropy secrets (such as
six-digit PIN) can provide sufficient security.
Their only limitation is the flipside of their strength: because they're
non-exportable, you can't back them up and move them between devices.
Once created, a hardware key is bound to the machine, unlike software
keys which are usable everywhere as long as you have keyring.cbor.
Hardware keys require TPM 2.0 and an API to communicate with it.
Implementations are provided for:
- Windows via Cryptography API: Next Generation (CNG) with Microsoft
Platform Crypto Provider.
- Unix systems with TPM2 Software Stack (TSS2).
Windows scopes keys to a Windows user, so you likely won't be able to
move them across users or installations within the same machine. The
keys will remain on the system with "SoF_Auth_" prefix and a UUID so you
can locate them in your key registry. They'll additionally have the name
you set at key creation.
Unix might require additoinal user permissions to access the TPM. For
example, adding a user to the `tss` group on Linux.
The platform input differs. Windows can take a user-friendly key name to
display, which is a good feature considering weird requirement of
Windows that key names (actual identifiers) must be unique strings, for
which I use UUIDs. Unix has no concept of key names or identifiers, but
it has to provide PIN to the TPM directly.
Windows uses its own PIN prompt from Windows Security UI that's
disconnected from the application. This is somewhat awkward because it's
modeless. Also, a ridiciulous quirk of Windows CNG API makes it so key
handle creation returns the same `NTE_INVALID_HANDLE` error no matter
what kind of error it was. In particular, it's impossible to
differentiate between the operation failing due to the TPM lockout, or
the user voluntarily closing the dialog. The user will always see
"hardware locked out" error message. Brilliant API design.
The PIN is implemented as a direct authorization value for keys, so it
might be vulnerable to the bus sniffing attack if the PIN is traveling
in clear between CPU and TPM. Though, a hypothetical adversary who's
sitting with a logic analyzer hooked up to your motherboard as you type
the PIN will realistically have easier means to log your keystrokes.
TPM is capable of remote attestation to prove its authenticity, but I
chose to avoid it to protect users' privacy (there's anonymous
attestation, but it's not always practical because it requires special
CAs) and avoid significant implementation complexity on the server that
the attestation entails, such as parsing and validating certificate
chains.
Because of the unfortunate reality, TPMs overwhelmingly have no support
for X25519 (the key exchange algorithm used in software keys). It was
added in a recent revision, but it's yet to be implemented, and only on
the newest machines. You can't upgrade the TPM hardware, so we have to
compromise. Instead, elliptic curve Diffie-Hellman over P-256 curve has
been selected, which is also the default curve used in WebAuthn
(passkey) protocol. It's ubiquitous, supported by every single TPM 2.0,
and secure if reasonably implemented.
Keys don't take up limited nonvolatile memory of the TPM. Every
reference to TPM objects necessary to perform authentication is stored
on disk, and keys and contexts are recreated on every operation and
cleared from memory afterwards.
For the client public key format, I *only* use compressed P-256 points
(1-byte parity of y coordinate followed by a full 32-byte x coordinate)
for robustness. Their designated identification byte is 0x33, and they
start with the letter M when base64url-encoded.
|
|
Remove -pipe because this option is dubious and doesn't do anything.
Get rid of unwind tables. They instrument call sites (synchronous) and
any instruction boundary (asynchronous). In the release build, they only
inflate the size of the executable. Synchronous tables are necessary
for C++ exceptions, but, thankfully (and I can't praise the developers
enough) AO2 Client doesn't use them at all.
Add RELRO and NOW to the linker. While I've already removed PLT at code
generation phase with -fno-plt, turns out, ld still stupidly performs
lazy linking: the symbols are moved to GOT, but not immediately
resolved. That was an oversight of mine, so bring back full RELRO.
Add packing of relative relocations. These are moved to a separate
compact section, where they're encoded more efficiently.
|
|
- Downstream version and the upstream revision it's based on
(commit and date)
- URL to our modified source code.
- miniaudio and libsodium versions.
- Build profile (release, dev, or debug).
Also, stop checking for updates.
|
|
The subprotocol shall use binary frames, and AO protocol stays separated
within the text frames.
|
|
Introduce start_auth_flow, a function invoked by typing `/auth username`
in OOC. It sends an public-key authentication request to the server,
starting the entire flow.
The flow invoves two dialogs: to select the key, and to enter the
passphrase to unlock the key. For convenience, each successful unlock
also remembers the key for that username on the server, storing this
in `saved_auth.json` (I chose JSON because I wanted it to stay
human-editable; INI would be better, but it suffers from bad platform
quirks in Qt).
|
|
Add "Keyring" tab to the options dialog. The tab displays the keys from
the table model (notes and certificates) and lets users create and
delete keys.
Key generation dialog includes passphare confirmation and a note.
|
|
The keyring provides the system to store secret keys in an encrypted
format, create and delete keys, display public keys and notes for the
user, and use these keys to peform public-key authentication on servers.
Keyring is serialized into `keyring.cbor` in the application directory.
It's a CBOR map with keys being key IDs (fingerprints), and the values
are key entries, the schema of which looks like this:
key-entry {
0 => uint, ; Algorithm tag, 1 byte
1 => text, ; Comment/note for the key
2 => bytes, ; Public key (certificate), 32 bytes
3 => bytes ; Encrypted and authenticated secret key (AEAD payload)
}
Key fingerprint is `BLAKE2b-256(tag || public_key)`, where `||` denotes
concatenation of byte strings.
Encrypted payload is a fixed binary structure (field sizes in bytes):
Version(1)
Salt(16)
Opslimit(4)
Memlimit(4)
Alg(1)
Ciphertext(32)
MAC(16)
Upon key generation, a new secret key is created, sourced from a secure
RNG. The wrap key is derived from the passphrase using Argon2 with
the specified iterations, memory cost, variant (3 iterations, 1 GB of
memory, Argon2id), and 16 bytes of randomly generated unique salt. This
wrap key is used with ChaCha20-Poly1305 to encrypt the secret key, with
all the prior fields as additional authenticatied data and all-zero
nonce (the uniqueness is already provided by the salt).
The key pairs are X25519, used specifically for key exchange. When the
server sends the ephemeral public key as a challenge, the client uses
`unlock_and_auth` function with the key corresponding to the right
certificate. After entering the correct passphrase, the secret key is
decrypted and used to derive a shared secret with the server's ephemeral
key. The client then responds with:
BLAKE2b-256("Einsof-Auth-DHCR" || shared_secret || challenge
|| certificate || username)
Where the first string is provided for domain separation, shared secret
proves possession of the secret key, and other parameters are hashed in
to bind this authentication attempt to the current session (via random
challenge), identity (via public key and username), and transcript.
Note on canonicalization: all fields but last are fixed-length,
concatenation here is unambiguous.
The server, in turn, performs the same opeations, except the shared
secret is derived from the server's ephemeral secret and the client's
public key. Naturally, username and public key must be correct. If the
response matches, the server authenticates the client. The client never
transmits its secret.
This scheme is essentially deriving a session secret and computing MAC
over the transcript with that secret to prove authenticity. It serves as
a simple identification protocol. Unlike digital signatures, it's
interactive, valid only in the context of a single authentication
attempt, and only between two participants involved. Signatures, in
contrast, are valid everywhere, for everyone, and they require
additional nonces and context. In fact, they're interactive
identification protocols turned non-interactive, so forcing them back
into this setting is unnecessary complexity.
The primitives are fixed: X25519 for key exchange, Argon2 for
password-based key derivation, ChaCha20-Poly1305 for encryption, BLAKE2b
for hashing. Provided by libsodium.
Simplicity is key. There's no flexibility, negotiation, or
compatibility, and it'll hopefully stay this way. Unless you're worried
about quantum computers appearing tomorrow and attacking a niche AO
implementation, in which case I'll add the ML-KEM variant just for you.
|
|
Introduce the subprotocol ("Einsof"), its prototype serialization and
parsing functions, and its first set of messages.
These messages are carriers of public-key authentication mechanism which
involves client request, server challenge, and client response. An
"ident" message is used to tell a compatible server that you support a
particular version of the subprotocol.
Note: the functions that handle encoding are very specialized.
They're not representative of how the wire format should be generally
handled, and were written this way because the first set of messages is
tiny and simple enough.
|
|
SFX and blip players largely remain the same.
For the music player, we now have to implement network streaming
natively, we no longer have a convenient function that did everything
for us. I introduced QNetworkRequest to download the stream in memory
and signal when it's ready to be decoded and played back. The size is
guarded to prevent the client from accidentally downloading terabytes of
audio.
Delete QFutureWatcher, we no longer need it for concurrency. miniaudio
uses a separate audio thread. Network donwloads and communication with
the track name display are handled by Qt signals.
Also, delete an odd "music.txt" feature. Its purpose was specifying
offsets for loops in a text file per track, but it remained obscure and
unused in practice.
Unsupported:
- Large streams, including unbounded ones (radio). We'll need a ring
buffer for that, and a mechanism to write to it from the network and
feed it to the audio thread.
- Effect flags: fade in, fade out, sync pos. Ignored.
- Audio device selection.
|
|
- Change CMake minimum version.
- Turn off tests and Discord RPC by default in CMake. Let these features
be explicitly enabled if desired.
- Add three build profiles: Dev, Debug, Release. Dev offers the fastest
unoptimized builds. Debug enables additional symbols, tracing, and
turns on Address Sanitizer. Release is aggressively optimized,
including LTO.
|
|
* Use unix timestamp to transmit ban duration
* Cleanup compiler warning due to narrowing conversion
* Fix preanim not being visible
This is apparently not a feature we want from WebAO :^)
* Bump to RC2
* Use std::chrono instead
* Remove random include and debug call
|
|
* Commit
* Boyfailure code commit
* Cooking code spaghetti
* Accidental overwrite recursive function call hell
* Implemented player list
* Add partial moderator widget
Sleepy time! Hee-Hoo!
* Moderator Dialog - Step 1 - WIP
* Appease the clang gods
* Clang appeasement policy
* *sacrifices goat to clang*
* Added player report, reworked implementation, ...
* Added player-specific report
* Reworked implementation
* No longer uses JSON.
* Removed preset loader.
---------
Co-authored-by: TrickyLeifa <date.epoch@gmail.com>
Co-authored-by: Leifa <26681464+TrickyLeifa@users.noreply.github.com>
|
|
* Remove TCP entry point
Resolve #987
* Remove TCP entry point
* Servers that do not support WebSocket will be marked as `Legacy`
* Removal of TCP connection from the master will follow later.
* Tweaked error message
|
|
* Removed MIDI, removed undocumented (yet supported) formats
Resolve #1006
* Adjusted CI for MIDI removal
|
|
* Added screen slide timer
* Added so that the animation becomes interruptible.
|
|
* Complete AOLayer reimplementation
* Reimplemented sliding as well.
|
|
|
|
|
|
* Reimplemented unit tests and simplified addition of new tests
* Minimal support of Qt is now 5.15
|
|
This comment format is just tiring for the eyes. Imagine being on 1080p and not being able to read more than 5 method definitions due to comments.
|
|
* Lightly reworked `NetworkManager`
* Added new modules to handle various connection types.
* TCP
* WebSocket
* Added general string splitter alias based on Qt version.
* Replaced `lobby_constructed` and `courtroom_constructed`
* Refactored and partially reimplemented the following classes:
* `AOBlipPlayer`
* `AOEmotePreview`
* `AOMusicPlayer`
* `AOSfxPlayer`
* `AOTextArea`
|
|
* Reworked favorite server widget
* Renamed `server_type` to `ServerInfo`
* Renamed `connection_type` to `ServerConnectionType`
* Refactored `AOCharButton`
* Reimplemented `AOButton`
* Partially reimplemented `AOEmoteButton`
* Refactored `AOEvidenceButton`
|
|
* Ported the project to CMake
* Android and Mac support dropped for the time
being.
* Tests, BASS and Discord-RPC are now options
* Restructured and reformated the project.
* Merged `include` and `src`
* Renamed `resource` to `data`
* Renamed various files
* External libraries headers are no longer included in `src`
* Replaced header guards with #pragma once
* Multiple refactors (keywords, headers)
* Added Qt6 compatibility
* Removed various unused functions and headers
* Reworked AOPacket
* When content is passed to AOPacket, it should be ensured that the content is already decoded.
* Encoding/decoding are now static methods.
* Fixed various memory leaks
* Removed animation code for AOImage
* AOImage is always using static images
* Simplified ChatLogPiece
|
|
* Add required macos frameworks
* Make building tests optional
* Add missing source and header files from cmakelists
|
|
seemlessly (#696)
* Replace TCP Serversocket with Websocket
* Have TCP sockets live harmoniously with WS
"like 5 lines" yeah probably lost a bet.
* Update .gitlab-ci.yml
* hack to fix favorites
* Add support for websockets in the favorites list (serverlist.txt)
Make "add_favorite_server" remember the socket type
* Preserve old serverlist style
This will keep new entries compatible with 2.9 and prior clients. Makes parsing the list easier too.
* Add lookup table and correct write code to use lowercase
* I have no idea what a lookup table is, but this looks close enough
* Fix lookup table
* Otherwise backend selection behaviour is inverted
* clang-tidy had one job
* Yet it did not do it.
Co-authored-by: oldmud0 <oldmud0@users.noreply.github.com>
* const p_data
* Switch serverlist.txt to an ini format
* Fixes an Omni bug where : would split the servername
* Utilises internally QSettings properly for low parsing effort and clear structure
* Automatically migrates the legacy serverlist.txt to favorite_servers.ini
* Pleases my OCD
* Replace sample serverlist.
Co-authored-by: oldmud0 <oldmud0@users.noreply.github.com>
Co-authored-by: stonedDiscord <Tukz@gmx.de>
Co-authored-by: Alex Noir <Varsash@gmail.com>
|
|
* add bassmidi everywhere but CI
* hello CI please don't ban me from github
* add lib and open midi files with the lib
* overlooked windows CI
* yes, overwrite everything
* add tracker support
* add file formats that bass supports
* forgot .mid smh
* load all plugins in one function
|
|
Variables accessed across threads should be atomic.
Also gave AOLayer its own thread pool and switched some lock calls to use QMutexLocker semantics.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
