CernVM-FS provides end-to-end data integrity and authenticity using a signed
Merkle Tree. CernVM-FS clients verify the signature and the content hashes of
all downloaded data. Once a particular revision of a file system is stored in
a client’s local cache, the client will not apply an older revision anymore.

The public key used to ultimately verify a repository’s signature needs to be
distributed to clients through a channel different from CernVM-FS content
distribution. In practice, these public keys are distributed as part of the
source code or through cvmfs-config-... packages. One or multiple public
keys can be configured for a repository (the fully qualified repository name),
all repositories within a specific domain (like *.cern.ch) or all
repositories (*). If multiple keys are configured, it is sufficient if any
of them validates a signature.

Besides the client, data is also verified by the replication code (Stratum 1 or
preloaded cache) and by the release manager machine in case the repository is
stored in S3 and not on a local file system.

CernVM-FS does not provide data confidentiality out of the box. By default
data is transferred through HTTP and thus only public data should be stored on
CernVM-FS. However, CernVM-FS can be operated with HTTPS data transport. In
combination with client-authentication using an authz helper (see Section
Authorization Helpers), CernVM-FS can be configured for end-to-end data
confidentiality.

Once downloaded and stored in a cache, the CernVM-FS client fully trusts the
cache. Data in the cache can be checked for silent corruption but no integrity
re-check takes place.

Creating and validating a repository signature is a two-step process. The
repository manifest (the file .cvmfspublished) is signed by a private RSA
key whose public part is stored in the form of an X.509 certificate in the
repository. The fingerprint of all certificates that are allowed to sign a
repository is stored on a repository whitelist (the file .cvmfswhitelist).
The whitelist is signed with a different RSA key, the repository master key.
Only the public part of this master key needs to be distributed to clients.

The X.509 certificate currently only serves as an envelope for the public part
of a repository key. No further certificate validation takes place.

The repository manifest contains, among other information, the content hash of
the root file catalog, the content hash of the signing certificate, the fully
qualified repository name, and a timestamp. In order to sign the manifest, the
content of the manifest is hashed and encrypted with a private repository key.
The timestamp and repository name are used prevent replay attacks.

The whitelist contains the fully qualified repository name, a creation
timestamp, an expiry timestamp, and the certificate fingerprints. Since the
whitelist expires, it needs to be regularly resigned.

The private part of the repository key needs to be accessible on the release
manager machine. The private part of the repository master key used to sign the
whitelist can be maintained on a file on the release manager machine.
We recommend, however, to use a smart card to store this private key.
See section Master keys for more details.

CernVM-FS supports multiple content hash algorithms: SHA-1 (default),
RIPEMD-160, and SHAKE-128 with 160 output bits. The content hash algorithm
can be changed with every repository publish operation. Files and file catalogs
hashed with different content hash algorithms can co-exist. On changing the
algorithm, new and changed files are hashed with the new algorithm, existing
data remains unchanged. That allows seamless migration from one algorithm to
another.

Most parts of CernVM-FS do not require root privileges. On the server side,
only creating and deleting a repository (or replica) requires root privileges.
Repository transactions and snapshots can be performed with an unprivileged user
account. In order to remount a new file system revision after publishing a
transaction, the release manager machines uses a custom suid binary.

On client side, the CernVM-FS fuse module is normally started as root. It drops
root privileges and changes the persona to the cvmfs user early in the file
system initialization. The client RPM package installs SElinux rules for RHEL6
and RHEL7. The cache directory should be labeled as cvmfs_cache_t.

CernVM-FS software is distributed through HTTPS in packages. There are yum and
apt repositories for Linux and pkg packages for OS X. Sofware is available
from HTTPS servers. The Linux packages and repositories are signed with a GPG
key.