There are ways of securing Broadcom ARM chips with DRM style protected memory/boot, but the version that ships with the pi is not enabled for obvious reasons.
LUKS Encryption also slows down everything, and on a resource limited system will be very noticeable.
You can encrypt the root mount too, but the program contents are already shared by hundreds of thousands of users.... so doesn't really make sense.
There are also trade-offs with using a shared key for allowing access to every user of a system, and so a single user home (and external disk key) per partition mount is usually the way to go. Some users will even mount a local file as a disk for a portable LUKS based system, but that is silly due to various duplicates of a file in cache.
One must use a one-time key system for the swap partition, and be mindful of services that index files for "find" or logs etc.
Recently, ext4 partitions added support for native user-level file encryption, but it is a method that can't be considered stable across the *nix ecosystem.
Some use an NFS to mount a remote resource, have a physical tamper detection circuit in the enclosure, and avoid the local access issues altogether.
And finally, public key systems like gpg by design allow one to compress local files into an encrypted state without knowing the private key. Unfortunately, this usually still leaves bits of the file in swap file memory and on other areas of unencrypted disks where the file was initially created.
So in conclusion:
1. check the signature of your boot area kernel files to detect alteration (not really possible on Pi)
2. check the signatures of fast-access area of unencrypted root application files (any changes to the binaries?)
3. use one-time key encrypted swaps
4. locally decrypt device and user specific disk mounts using external key/resources off an NFS
6. login to account to use file level encryption
7. read XKCD to understand why none of this matters: https://www.xkcd.com/538/
If you are designing a product, than you should focus on DRM systems like the one Nintendo chose:
Personally, I buy things that don't have these DRM features for obvious reasons, as it is essentially a factory deployed root-kit with zero accountability (see Intel management engine for details).
Best of luck,