If the question is taken literally, then yes, you cannot add a new file to an encrypted hard drive. If your question is instead better phrased as "can an attacker modify data on an encrypted hard drive without knowing the key?", then the answer is that it depends on the mode of operation being used, but it is very possible.
Encrypting data requires two algorithms: the cipher itself (such as AES), and a mode of operation (such as CBC). The cipher can be assumed to be secure in all realistic circumstances, but the mode of operation may either be quite secure, or may give away a large amount of information about the encrypted data or worse, depending on how it is used. Each mode of operation has its pros and cons, and is only supposed to be used for specific purposes. Some examples:
- ECB: extremely simple, safe when used only to encrypt a single block of data with a given key
- CTR: very fast and does not need to encrypt in multiples of one block, so common in networking
- GCM: similar to CTR, but prevents tampering at the expense of space efficiency
- CBC: pretty simple, useful to encrypt individual files where integrity is not important
- XTS: more complicated than the others, but useful to encrypt block devices like hard drives
- EME: better for block device encryption than XTS, but patent encumbered so rarely used
Encrypted hard drives typically use either CBC or XTS. With CBC, the answer to your question is no, it does not stop someone from adding or modifying data, though it does stop them from adding whole, intact files as that would require fine control over various complicated filesystem structures. CBC is vulnerable to so-called malleability attacks, which allow targeted manipulation of already encrypted data (see Practical malleability attack against CBC-Encrypted LUKS partitions). While someone couldn't simply add an entire new file, they could, for example, modify an existing executable file to add malicious behavior. A description of the capabilities of this attack against CBC, from the above paper:
We can use this technique to change every 2nd plaintext block in a sector to anything we want to while destroying the blocks between the manipulated blocks. Given a blocksize of 16 bytes (128 bits) this does allow injecting more or less arbitrary shellcode to an executable file by dividing the shellcode to small chunks and adding JMP instructions to jump over the garbage blocks.
This allows for a scary level of control over your encrypted data. While the confidentiality of the data itself is still guaranteed with essentially all modes of operation (with the exception of ECB, which results in the famous ECB penguin when used to encrypt more than a single block of data), you probably wouldn't want to use this mode if you expect someone may be able to tamper with your data.
XTS is not perfect and does not guarantee integrity of the data, it does prevent such targeted modifications. With XTS, you can corrupt an arbitrary 16 byte block of data, but you cannot choose what the modified data will decrypt to. While this is not nearly as bad as being able to insert arbitrary data, it can still be dangerous. For example, it could be used to cut out vital permission checks from within the machine code of an executable, making it vulnerable.
There are special block modes called wide-block modes (such as XCB and EME/EME2) which are similar to XTS, but increase the minimum block size for tampering up to the size of a single sector (typically 512 bytes). An attacker who can corrupt an arbitrary 512 bytes is much less dangerous than one who can corrupt an arbitrary 16 bytes (or 1 bit, if something silly like CTR is used!). Unfortunately, these block modes are or have for most of their lives been patented, which hinders their adoption.
Authenticated modes like GCM provide perfect integrity on top of the confidentiality provided by the cipher, so that if any ciphertext is modified without knowing the key, it will not decrypt at all, rather than decrypting to corrupted plaintext. The problem with authenticated modes is that they require a little bit of extra integrity data called a MAC after every message. This is fine for things like networking to replace CTR, where the MAC is sent after a long stream of ciphertext, but a hard drive requires being able to read and write with per-sector granularity, so each sector would need to contain its own MAC, greatly reducing the amount of space available for storing data.
Most hard drive encryption software uses either CBC or XTS, though some versions of Windows include a "diffuser", which acts similar to wide-block modes by increasing the minimum tampering size. For something like Linux, a drive may be encrypted with aes-cbc-essiv when in CBC mode, or aes-xts-plain64 when in XTS mode. You can check what mode is being used by running the command dmsetup table as root.
