WARNING: This version is full of breaking changes. Please see the Breaking section for more details
Features
The headlining feature for this release is U2F support. All existing keys continue to work but new APIs have been added to support the registration and verification of U2F keys.
While PIV keys are still supported and continue to be my preferred method for server key storage, users may want to consider moving users to FIDO tokens as there are a couple features those provide:
- Ed25519 support
- Non resident keys
- More flexibility in supported authenticator type.
Ed25519
The Ed25519 support is a welcome addition as a non NIST curve with no magic values. This makes it preferable to use in scenarios where is concern about potential, intentional, weaknesses within those algorithms.
Non Resident/Discoverable Keys
Non resident (sometimes called "non discoverable") keys is also a significant security improvement as it does not store the private key on the device. Instead the private key is stored in a form that only the device can decrypt and signing works by passing this data to the device and asking for a signature using the decrypted key. This means that a loss of a Yubikey does not result in a loss of key material as PIV keys do. Even though pins on PIV keys in theory prevent the same thing, there is no way to guarantee a user is not using the default pin on a device.
Authenticator Flexibility
This update also opens the door to being able to use non Yubikey hardware devices for the first time. Currently, Rustica only validates Yubikey attestation chains but this can be changed and will be made more flexible in a future update.
Watch Out For
One of the drawbacks of using FIDO is that FIDO attestations do not contains the device serial number for privacy reasons. In theory RusticaAgent could fetch the serial number from the device but the server would have no way to validate the client was not lying about it. If your enterprise uses the serial number feature to authorize usage of issued yubikeys, you will not be able to use the FIDO system as a drop in replacement.
Breaking
In order to build all these features and not spend forever working on backwards compatibility which would also pollute the API, I decided 0.9 would be breaking in many ways.
The Database
The database schema has been updated to be able to hold attestation data for both PIV and U2F keys. Going forward should be easy as we are just adding columns, but going backwards is not. SQLite does not support the removal of columns in a schema which means the only way to go back is to delete the table and recreate it. The migration code does not attempt to migrate the data backwards when this happens so it is highly advisable to backup your database before hand.
External Authorization Services
The changes here are less severe and by the very nature of running an external service you've had to get your hands dirtier than use running Rustica itself. There are slight changes to calls made to external authorization services to differentiate between a U2F and PIV registration which will need to be handled.
The Config
A new mandatory configuration flag has been added which controls if Rustica will allow users to register keys that do not have valid attestation chains. Turning this on increases security but means that hosts cannot be registered (as they register key files which have no chain). Setting this flag to false emulates the behaviour of Rustica <0.9 where keys without or an invalid attestation chain will continue to register but without that validatation.
RusticaAgent
This is an unfortunate incompatibility but to simplify the secure mode operation (where Rustica validates a signature from the client before providing a certificate), the challenge was converted from a random binary string to a challenge SSH certificate. This allowed verification to be the same for both PIV and U2F (as verification is handled by the SSHCerts library) but it meant that the challenge was no longer a hex encoded string. This means this new version of the server, is incompatible with previous version of RusticaAgent, even if that feature is turned off because of when this check happened. There may be forwards compatibility with PIV with RusticaAgent 0.9 and Rustica server 0.8 but this is not tested or recommended.
Possible Migration Strategies
Running Alongside
If using AmazonKMS or file based keys, this is an easy migration strategy. Running a separate instance either with a database clone or pointing to the same external service will allow users to migrate over to the new version within a given time window and then the old version can be deprecated and shutdown. If using a Yubikey this becomes more difficult requiring either migrating keys or provisioning a new Yubikey with the same keys if possible (only if keys were imported to the Yubikey to start with).
Temporary Long Lived Certificates
Rustica enables the usage of ultra short lived certificates but they don't have to be. A possible solution if a hard cutover must be done (due to reasons or restrictions above) is to allow users to fetch certificates that are valid for the period of time needed to do the migration (hours to days). Users will then not need to contact the Rustica server while they have this giving time for the migration to occur. This does pose some challenges as if their RusticaAgent daemon dies they will lose the certificate without a way to get another, but it is a possible avenue of investigation.