File:  [NetBSD Developer Wiki] / wikisrc / guide / cgd.mdwn
Revision 1.5: download - view: text, annotated - select for diffs
Fri Jun 19 19:18:31 2015 UTC (5 years, 1 month ago) by plunky
Branches: MAIN
CVS tags: HEAD
replace direct links to manpages on netbsd.gw.com with templates

    1: **Contents**
    2: 
    3: [[!toc levels=3]]
    4: 
    5: # The cryptographic device driver (CGD)
    6: 
    7: The [[!template id=man name="cgd" section="4"]] driver
    8: provides functionality which allows you to use disks or partitions for encrypted
    9: storage. After providing the appropriate key, the encrypted partition is
   10: accessible using `cgd` pseudo-devices.
   11: 
   12: ## Overview
   13: 
   14: People often store sensitive information on their hard disks and are concerned
   15: about this information falling into the wrong hands. This is particularly
   16: relevant to users of laptops and other portable devices, or portable media,
   17: which might be stolen or accidentally misplaced.
   18: 
   19: ### Why use disk encryption?
   20: 
   21: File-oriented encryption tools like GnuPG are great for encrypting individual
   22: files, which can then be sent across untrusted networks as well as stored
   23: encrypted on disk. But sometimes they can be inconvenient, because the file must
   24: be decrypted each time it is to be used; this is especially cumbersome when you
   25: have a large collection of files to protect. Any time a security tool is
   26: cumbersome to use, there's a chance you'll forget to use it properly, leaving
   27: the files unprotected for the sake of convenience.
   28: 
   29: Worse, readable copies of the encrypted contents might still exist on the hard
   30: disk. Even if you overwrite these files (using `rm -P`) before unlinking them,
   31: your application software might make temporary copies you don't know about, or
   32: have been paged to swapspace - and even your hard disk might have silently
   33: remapped failing sectors with data still in them.
   34: 
   35: The solution is to simply never write the information unencrypted to the hard
   36: disk. Rather than taking a file-oriented approach to encryption, consider a
   37: block-oriented approach - a virtual hard disk, that looks just like a normal
   38: hard disk with normal filesystems, but which encrypts and decrypts each block on
   39: the way to and from the real disk.
   40: 
   41: ### Logical Disk Drivers
   42: 
   43: The `cgd` device looks and behaves to the rest of the operating system like any
   44: other disk driver. Rather than driving real hardware directly, it provides a
   45: logical function layered on top of another block device. It has a special
   46: configuration program,
   47: [[!template id=man name="cgdconfig" section="8"]],
   48: to create and configure a `cgd` device and point it at the underlying disk
   49: device that will hold the encrypted data.
   50: 
   51: NetBSD includes several other similar logical block devices, each of which
   52: provides some other function where `cgd` provides encryption. You can stack
   53: several of these logical block devices together: you can make an encrypted
   54: `raid` to protect your encrypted data against hard disk failure as well.
   55: 
   56: Once you have created a `cgd` disk, you can use
   57: [[!template id=man name="disklabel" section="8"]]
   58: to divide it up into partitions,
   59: [[!template id=man name="swapctl" section="8"]] to
   60: enable swapping to those partitions or
   61: [[!template id=man name="newfs" section="8"]] to make
   62: filesystems, then `mount` and use those filesystems, just like any other new
   63: disk.
   64: 
   65: ## Components of the Crypto-Graphic Disk system
   66: 
   67: A number of components and tools work together to make the `cgd` system
   68: effective.
   69: 
   70: ### Kernel driver pseudo-device
   71: 
   72: To use `cgd` you need a kernel with support for the `cgd` pseudo-device. Make
   73: sure the following line is in the kernel configuration file:
   74: 
   75:     pseudo-device   cgd     4       # cryptographic disk driver
   76: 
   77: The number specifies how many `cgd` devices may be configured at the same time.
   78: After configuring the `cgd` pseudo-device you can recompile the kernel and boot
   79: it to enable `cgd` support.
   80: 
   81: ### Ciphers
   82: 
   83: The `cgd` driver provides the following encryption algorithms:
   84: 
   85:  * `aes-cbc` -- AES (Rijndael). AES uses a 128 bit blocksize and accepts 128,
   86:    192 or 256 bit keys.
   87: 
   88:  * `blowfish-cbc` -- Blowfish uses a 64 bit blocksize and accepts 128 bit keys
   89: 
   90:  * `3des-cbc` -- Triple DES uses a 64 bit blocksize and accepts 192 bit keys
   91:    (only 168 bits are actually used for encryption)
   92: 
   93: All three ciphers are used in [CBC (Cipher Block
   94: Chaining)](http://en.wikipedia.org/wiki/Cipher_block_chaining)
   95: mode. This means each block is XORed with the previous encrypted block before
   96: encryption. This reduces the risk that a pattern can be found, which can be used
   97: to break the encryption.
   98: 
   99: ### Verification Methods
  100: 
  101: Another aspect of `cgd` that needs some attention are the verification methods
  102: `cgdconfig` provides. These verification methods are used to verify the
  103: passphrase is correct. The following verification methods are available:
  104: 
  105:  * `none` -- no verification is performed. This can be dangerous, because the
  106:    key is not verified at all. When a wrong key is entered, `cgdconfig`
  107:    configures the `cgd` device as normal, but data which was available on the
  108:    volume will be destroyed (decrypting blocks with a wrong key will result in
  109:    random data, which will result in a regeneration of the disklabel with the
  110:    current key).
  111: 
  112:  * `disklabel` -- `cgdconfig` scans for a valid disklabel. If a valid disklabel
  113:    is found with the key that is provided authentication will succeed.
  114: 
  115:  * `ffs` -- `cgdconfig` scans for a valid FFS file system. If a valid FFS file
  116:    system is found with the key that is provided authentication will succeed.
  117: 
  118: ## Example: encrypting your disk
  119: 
  120: This section works through a step-by-step example of converting an existing
  121: system to use `cgd`, performing the following actions:
  122: 
  123:  1. Preparing the disk and partitions
  124:  2. Scrub off all data
  125:  3. Create the cgd
  126:  4. Adjust config-files
  127:  5. Restoring your backed-up files to the encrypted disk
  128: 
  129: ### Preparing the disk
  130: 
  131: First, decide which filesystems you want to move to an encrypted device. You're
  132: going to need to leave at least the small root (`/`) filesystem unencrypted, in
  133: order to load the kernel and run `init`, `cgdconfig` and the `rc.d` scripts that
  134: configure your `cgd`. In this example, we'll encrypt everything except the root
  135: (`/`) filesystem.
  136: 
  137: We are going to delete and re-make partitions and filesystems, and will require
  138: a backup to restore the data. So make sure you have a current, reliable backup
  139: stored on a different disk or machine. Do your backup in single-user mode, with
  140: the filesystems unmounted, to ensure you get a clean
  141: [[!template id=man name="dump" section="8"]]. Make sure you
  142: back up the disklabel of your hard disk as well, so you have a record of the
  143: partition layout before you started.
  144: 
  145: With the system at single user, `/` mounted read-write and everything else
  146: unmounted, use
  147: [[!template id=man name="disklabel" section="8"]]
  148: to delete all the data partitions you want to move into `cgd`.
  149: 
  150: Then make a single new partition in all the space you just freed up, say,
  151: `wd0e`. Set the partition type for this partition to `cgd` Though it doesn't
  152: really matter what it is, it will help remind you that it's not a normal
  153: filesystem later. When finished, label the disk to save the new partition table.
  154: 
  155: ### Scrubbing the disk
  156: 
  157: We have removed the partition table information, but the existing filesystems
  158: and data are still on disk. Even after we make a `cgd` device, create
  159: filesystems, and restore our data, some of these disk blocks might not yet be
  160: overwritten and still contain our data in plaintext. This is especially likely
  161: if the filesystems are mostly empty. We want to scrub the disk before we go
  162: further.
  163: 
  164: We could use
  165: [[!template id=man name="dd" section="1"]]
  166: to copy `/dev/zero` over the new `wd0e` partition, but this will leave our disk
  167: full of zeros, except where we've written encrypted data later. We might not
  168: want to give an attacker any clues about which blocks contain real data, and
  169: which are free space, so we want to write "noise" into all the disk blocks. So
  170: we'll create a temporary `cgd`, configured with a random, unknown key.
  171: 
  172: First, we configure a `cgd` to use a random key:
  173: 
  174:     # cgdconfig -s cgd0 /dev/wd0e aes-cbc 128 < /dev/urandom
  175: 
  176: Now we can write zeros into the raw partition of our `cgd` (`/dev/rcgd0d` on
  177: NetBSD/i386, `/dev/rcgd0c` on most other platforms):
  178: 
  179:     # dd if=/dev/zero of=/dev/rcgd0d bs=32k
  180: 
  181: The encrypted zeros will look like random data on disk. This might take a while
  182: if you have a large disk. Once finished, unconfigure the random-key `cgd`:
  183: 
  184:     # cgdconfig -u cgd0
  185: 
  186: ### Creating the `cgd`
  187: 
  188: The
  189: [[!template id=man name="cgdconfig" section="8"]]
  190: program, which manipulates `cgd` devices, uses parameters files to store such
  191: information as the encryption type, key length, and a random password salt for
  192: each `cgd`. These files are very important, and need to be kept safe - without
  193: them, you will not be able to decrypt the data!
  194: 
  195: We'll generate a parameters file and write it into the default location (make
  196: sure the directory `/etc/cgd` exists and is mode 700):
  197: 
  198:     # cgdconfig -g -V disklabel -o /etc/cgd/wd0e aes-cbc 256
  199: 
  200: This creates a parameters file `/etc/cgd/wd0e` describing a `cgd` using the
  201: `aes-cbc` cipher method, a key verification method of `disklabel`, and a key
  202: length of `256` bits. It will look something like this:
  203: 
  204:     algorithm aes-cbc;
  205:     iv-method encblkno;
  206:     keylength 256;
  207:     verify_method disklabel;
  208:     keygen pkcs5_pbkdf2/sha1 {
  209:             iterations 6275;
  210:             salt AAAAgHTg/jKCd2ZJiOSGrgnadGw=;
  211:     };
  212: 
  213: *Note*: Remember, you'll want to save this file somewhere safe later.
  214: 
  215: *Tip*: When creating the parameters file, `cgdconfig` reads from `/dev/random`
  216: to create the password salt. This read may block if there is not enough
  217: collected entropy in the random pool. This is unlikely, especially if you just
  218: finished overwriting the disk as in the previous step, but if it happens you can
  219: press keys on the console and/or move your mouse until the `rnd` device gathers
  220: enough entropy.
  221: 
  222: Now it's time to create our `cgd`, for which we'll need a passphrase. This
  223: passphrase needs to be entered every time the `cgd` is opened, which is usually
  224: at each reboot. The encryption key is derived from this passphrase and the salt.
  225: Make sure you choose something you won't forget, and others won't guess.
  226: 
  227: The first time we configure the `cgd`, there is no valid disklabel on the
  228: logical device, so the validation mechanism we want to use later won't work. We
  229: override it this one time:
  230: 
  231:     # cgdconfig -V re-enter cgd0 /dev/wd0e
  232: 
  233: This will prompt twice for a matching passphrase, just in case you make a typo,
  234: which would otherwise leave you with a `cgd` encrypted with a passphrase that's
  235: different to what you expected.
  236: 
  237: Now that we have a new `cgd`, we need to partition it and create filesystems.
  238: Recreate your previous partitions with all the same sizes, with the same letter
  239: names.
  240: 
  241: *Tip*: Remember to use the `disklabel -I` argument, because you're creating an
  242: initial label for a new disk.
  243: 
  244: *Note*: Although you want the sizes of your new partitions to be the same as the
  245: old, unencrypted ones, the offsets will be different because they're starting at
  246: the beginning of this virtual disk.
  247: 
  248: Then, use
  249: [[!template id=man name="newfs" section="8"]] to
  250: create filesystems on all the relevant partitions. This time your partitions
  251: will reflect the `cgd` disk names, for example:
  252: 
  253:     # newfs /dev/rcgd0h
  254: 
  255: ### Modifying configuration files
  256: 
  257: We've moved several filesystems to another (logical) disk, and we need to update
  258: `/etc/fstab` accordingly. Each partition will have the same letter (in this
  259: example), but will be on `cgd0` rather than `wd0`. So you'll have `/etc/fstab`
  260: entries something like this:
  261: 
  262:     /dev/wd0a   /     ffs     rw    1 1
  263:     /dev/cgd0b  none  swap    sw            0 0
  264:     /dev/cgd0b  /tmp  mfs     rw,-s=132m    0 0
  265:     /dev/cgd0e  /var  ffs     rw            1 2
  266:     /dev/cgd0f  /usr  ffs     rw            1 2
  267:     /dev/cgd0h  /home ffs     rw            1 2
  268: 
  269: *Note*: `/tmp` should be a separate filesystem, either `mfs` or `ffs`, inside
  270: the `cgd`, so that your temporary files are not stored in plain text in the `/`
  271: filesystem.
  272: 
  273: Each time you reboot, you're going to need your `cgd` configured early, before
  274: [[!template id=man name="fsck" section="8"]] runs and
  275: filesystems are mounted.
  276: 
  277: Put the following line in `/etc/cgd/cgd.conf`:
  278: 
  279:     cgd0    /dev/wd0e
  280: 
  281: This will use `/etc/cgd/wd0e` as config file for `cgd0`.
  282: 
  283: To finally enable cgd on each boot, put the following line into `/etc/rc.conf`:
  284: 
  285:     cgd=YES
  286: 
  287: You should now be prompted for `/dev/cgd0`'s passphrase whenever `/etc/rc`
  288: starts.
  289: 
  290: ### Restoring data
  291: 
  292: Next, mount your new filesystems, and
  293: [[!template id=man name="restore" section="8"]] your
  294: data into them. It often helps to have `/tmp` mounted properly first, as
  295: `restore` can use a fair amount of temporary space when extracting a large
  296: dumpfile.
  297: 
  298: To test your changes to the boot configuration, umount the filesystems and
  299: unconfigure the `cgd`, so when you exit the single-user shell, *rc* will run
  300: like on a clean boot, prompting you for the passphrase and mounting your
  301: filesystems correctly. Now you can bring the system up to multi-user, and make
  302: sure everything works as before.
  303: 
  304: ## Example: encrypted CDs/DVDs
  305: 
  306: ### Introduction
  307: 
  308: This section explains how to create and use encrypted CDs/DVDs with NetBSD (all
  309: I say about CDs here does also apply to DVDs). I assume that you have basic
  310: knowledge of cgd(4), so I will not explain what cgd is or what's inside it in
  311: detail. The same applies to vnd(4). One can make use of encrypted CDs after
  312: reading this howto, but for more detailed information about different cgd
  313: configuration options, please read the previous parts or the manpages.
  314: 
  315: ### Creating an encrypted CD/DVD
  316: 
  317: cgd(4) provides highly secure encryption of whole partitions or disks.
  318: Unfortunately, creating "normal" CDs is not disklabeling something and running
  319: newfs on it. Neither can you just put a CDR into the drive, configure cgd and
  320: assume it to write encrypted data when syncing. Standard CDs contain at least an
  321: ISO-9660 filesystem created with mkisofs(8) from the
  322: [`sysutils/cdrtools`](http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/cdrtools/README.html)
  323: package. ISO images must *not* contain disklabels or cgd partitions.
  324: 
  325: But of course CD reader/writer hardware doesn't care about filesystems at all.
  326: You can write raw data to the CD if you like - or an encrypted FFS filesystem,
  327: which is what we'll do here. But be warned, there is NO way to read this CD with
  328: any OS except NetBSD - not even other BSDs due to the lack of cgd.
  329: 
  330: The basic steps when creating an encrypted CD are:
  331: 
  332:  * Create an (empty) imagefile
  333:  * Register it as a virtual disk using vnd(4)
  334:  * Configure cgd inside the vnd disk
  335:  * Copy content to the cgd
  336:  * Unconfigure all (flush!)
  337:  * Write the image on a CD
  338: 
  339: The first step when creating an encrypted CD is to create a single image file
  340: with dd. The image may not grow, so make it large enough to allow all CD content
  341: to fit into. Note that the whole image gets written to the CD later, so creating
  342: a 700 MB image for 100 MB content will still require a 700 MB write operation to
  343: the CD. Some info on DVDs here: DVDs are only 4.7 GB in marketing language.
  344: 4.7GB = 4.7 x 1024 x 1024 x 1024 = 5046586573 bytes. In fact, a DVD can only
  345: approximately hold 4.7 x 1000 x 1000 x 1000 = 4700000000 bytes, which is about
  346: 4482 MB or about 4.37 GB. Keep this in mind when creating DVD images. Don't
  347: worry for CDs, they hold "real" 700 MB (734003200 Bytes).
  348: 
  349: Invoke all following commands as root!
  350: 
  351: For a CD:
  352: 
  353:     # dd if=/dev/zero of=image.img bs=1m count=700
  354: 
  355: or, for a DVD:
  356: 
  357:     # dd if=/dev/zero of=image.img bs=1m count=4482
  358: 
  359: Now configure a
  360: [[!template id=man name="vnd" section="4"]]-pseudo
  361: disk with the image:
  362: 
  363:     # vnconfig vnd0 image.img
  364: 
  365: In order to use cgd, a so-called parameter file, describing encryption
  366: parameters and a containing "password salt" must be generated. We'll call it
  367: `/etc/cgd/image` here. You can use one parameter file for several encrypted
  368: partitions (I use one different file for each host and a shared file `image` for
  369: all removable media, but that's up to you).
  370: 
  371: I'll use AES-CBC with a keylength of 256 bits. Refer to
  372: [[!template id=man name="cgd" section="4"]] and
  373: [[!template id=man name="cgdconfig" section="8"]]
  374: for details and alternatives.
  375: 
  376: The following command will create the parameter file as `/etc/cgd/image`. *YOU
  377: DO NOT WANT TO INVOKE THE FOLLOWING COMMAND AGAIN* after you burnt any CD, since
  378: a recreated parameter file is a lost parameter file and you'll never access your
  379: encrypted CD again (the "salt" this file contains will differ among each call).
  380: Consider this file being *HOLY, BACKUP IT* and *BACKUP IT AGAIN!* Use switch -V
  381: to specify verification method "disklabel" for the CD (cgd cannot detect whether
  382: you entered a valid password for the CD later when mounting it otherwise).
  383: 
  384:     # cgdconfig -g -V disklabel aes-cbc 256 > /etc/cgd/image
  385: 
  386: Now it's time to configure a cgd for our vnd drive. (Replace slice `d` with `c`
  387: for all platforms that use `c` as the whole disk (where
  388: `sysctl kern.rawpartition` prints `2`, not `3`); if you're on i386 or amd64, `d`
  389: is OK for you):
  390: 
  391:     # cgdconfig -V re-enter cgd1 /dev/vnd0d /etc/cgd/image
  392: 
  393: The `-V re-enter` option is necessary as long as the cgd doesn't have a
  394: disklabel yet so we can access and configure it. This switch asks for a password
  395: twice and uses it for encryption.
  396: 
  397: Now it's time to create a disklabel inside the cgd. The defaults of the label
  398: are ok, so invoking disklabel with
  399: 
  400:     # disklabel -e -I cgd1
  401: 
  402: and leaving vi with `:wq` immediately will do.
  403: 
  404: Let's create a filesystem on the cgd, and finally mount it somewhere:
  405: 
  406:     # newfs /dev/rcgd1a
  407:     # mount /dev/cgd1a /mnt
  408: 
  409: The cgd is alive! Now fill `/mnt` with content. When finished, reverse the
  410: configuration process. The steps are:
  411: 
  412: 1.  Unmounting the cgd1a:
  413: 
  414:         # umount /mnt
  415: 
  416: 2.  Unconfiguring the cgd:
  417: 
  418:         # cgdconfig -u cgd1
  419: 
  420: 3.  Unconfiguring the vnd:
  421: 
  422:         # vnconfig -u vnd0
  423: 
  424: 
  425: The following commands are examples to burn the images on CD or DVD. Please
  426: adjust the `dev=` for cdrecord or the `/dev/rcd0d` for growisofs. Note the
  427: `r` on the `rcd0d` *is* necessary with NetBSD. Growisofs is available in the
  428: [`sysutils/dvd+rw-tools`](http://ftp.NetBSD.org/pub/pkgsrc/current/pkgsrc/sysutils/dvd+rw-tools/README.html)
  429: package. Again, use `c` instead of `d` if this is the raw partition on your
  430: platform.
  431: 
  432: Finally, write the image file to a CD:
  433: 
  434:     # cdrecord dev=/dev/rcd0d -v image.img
  435: 
  436: ...or to a DVD:
  437: 
  438:     # growisofs -dvd-compat -Z /dev/rcd0d=image.img
  439: 
  440: Congratulations! You've just created a really secure CD!
  441: 
  442: ### Using an encrypted CD/DVD
  443: 
  444: After creating an encrypted CD as described above, we're not done yet - what
  445: about mounting it again? One might guess, configuring the cgd on `/dev/cd0d` is
  446: enough - no, it is not.
  447: 
  448: NetBSD cannot access FFS file systems on media that is not 512 bytes/sector
  449: format. It doesn't matter that the cgd on the CD is, since the CD's disklabel
  450: the cgd resides in has 2048 bytes/sector.
  451: 
  452: But the CD driver cd(4) is smart enough to grant write access to the
  453: (emulated) disklabel on the CD. So before configuring the cgd, let's have a look
  454: at the disklabel and modify it a bit:
  455: 
  456:     # disklabel -e cd0
  457:     # /dev/rcd0d:
  458:     type: ATAPI
  459:     disk: mydisc
  460:     label: fictitious
  461:     flags: removable
  462:     bytes/sector: 2048    # -- Change to 512 (= orig / 4)
  463:     sectors/track: 100    # -- Change to 400 (= orig * 4)
  464:     tracks/cylinder: 1
  465:     sectors/cylinder: 100 # -- Change to 400 (= orig * 4)
  466:     cylinders: 164
  467:     total sectors: 16386  # -- Change to value of slice "d" (=65544)
  468:     rpm: 300
  469:     interleave: 1
  470:     trackskew: 0
  471:     cylinderskew: 0
  472:     headswitch: 0           # microseconds
  473:     track-to-track seek: 0  # microseconds
  474:     drivedata: 0
  475:     
  476:     4 partitions:
  477:     #     size  offset  fstype [fsize bsize cpg/sgs]
  478:      a:   65544   0     4.2BSD  0     0     0  # (Cyl. 0 - 655+)
  479:      d:   65544   0     ISO9660 0     0        # (Cyl. 0 - 655+)
  480: 
  481: Now as the disklabel is in 512 b/s format, accessing the CD is as easy as:
  482: 
  483:     # cgdconfig cgd1 /dev/cd0d /etc/cgd/image
  484:     # mount -o ro /dev/cgd1a /mnt
  485: 
  486: Note that the cgd *MUST* be mounted read-only or you'll get illegal command
  487: errors from the cd(4) driver which can in some cases make even mounting a
  488: CD-based cgd impossible!
  489: 
  490: Now we're done! Enjoy your secure CD!
  491: 
  492:     # ls /mnt
  493: 
  494: Remember you have to reverse all steps to remove the CD:
  495: 
  496:     # umount /mnt
  497:     # cgdconfig -u cgd1
  498:     # eject cd0
  499: 
  500: ## Suggestions and Warnings
  501: 
  502: You now have your filesystems encrypted within a `cgd`. When your machine is
  503: shut down, the data is protected, and can't be decrypted without the passphrase.
  504: However, there are still some dangers you should be aware of, and more you can
  505: do with `cgd`. This section documents several further suggestions and warnings
  506: 	that will help you use `cgd` effectively.
  507: 
  508:  * Use multiple `cgd`'s for different kinds of data, one mounted all the time
  509:    and others mounted only when needed.
  510: 
  511:  * Use a `cgd` configured on top of a `vnd` made from a file on a remote network
  512:    fileserver (NFS, SMBFS, CODA, etc) to safely store private data on a shared
  513:    system. This is similar to the procedure for using encrypted CDs and DVDs
  514:    described in [[Example: encrypted CDs/DVDs|guide/cgd#cryptocds]].
  515: 
  516: ### Using a random-key cgd for swap
  517: 
  518: You may want to use a dedicated random-key `cgd` for swap space, regenerating
  519: the key each reboot. The advantage of this is that once your machine is
  520: rebooted, any sensitive program memory contents that may have been paged out are
  521: permanently unrecoverable, because the decryption key is never known to you.
  522: 
  523: We created a temporary `cgd` with a random key when scrubbing the disk in the
  524: example above, using a shorthand `cgdconfig -s` invocation to avoid creating a
  525: parameters file.
  526: 
  527: The `cgdconfig` params file includes a *randomkey* keygen method. This is more
  528: appropriate for *permanent* random-key configurations, and facilitates the easy
  529: automatic configuration of these volumes at boot time.
  530: 
  531: For example, if you wanted to convert your existing `/dev/wd0b` partition to a
  532: dedicated random-key cgd1, use the following command to generate
  533: `/etc/cgd/wd0b`:
  534: 
  535:     # cgdconfig -g -o /etc/cgd/wd0b -V none -k randomkey blowfish-cbc
  536: 
  537: When using the randomkey keygen method, only verification method `none` can be
  538: used, because the contents of the new `cgd` are effectively random each time
  539: (the previous data decrypted with a random key). Likewise, the new disk will not
  540: have a valid label or partitions, and `swapctl` will complain about
  541: configuring swap devices not marked as such in a disklabel.
  542: 
  543: In order to automate the process of labeling the disk, prepare an appropriate
  544: disklabel and save it to a file, for example `/etc/cgd/wd0b.disklabel`. Please
  545: refer to
  546: [[!template id=man name="disklabel" section="8"]]
  547: for information about how to use `disklabel` to set up a swap partition.
  548: 
  549: On each reboot, to restore this saved label to the new `cgd`, create the
  550: `/etc/rc.conf.d/cgd` file as below:
  551: 
  552:     swap_device="cgd1"
  553:     swap_disklabel="/etc/cgd/wd0b.disklabel"
  554:     start_postcmd="cgd_swap"
  555:     
  556:     cgd_swap()
  557:     {
  558:         if [ -f $swap_disklabel ]; then
  559:             disklabel -R -r $swap_device $swap_disklabel
  560:         fi
  561:     }
  562: 
  563: The same technique could be extended to encompass using `newfs` to re-create
  564: an `ffs` filesystem for `/tmp` if you didn't want to use `mfs`.
  565: 
  566: ### Warnings
  567: 
  568: Prevent cryptographic disasters by making sure you can always recover your
  569: passphrase and parameters file. Protect the parameters file from disclosure,
  570: perhaps by storing it on removable media as above, because the salt it contains
  571: helps protect against dictionary attacks on the passphrase.
  572: 
  573: Keeping the data encrypted on your disk is all very well, but what about other
  574: copies? You already have at least one other such copy (the backup we used during
  575: this setup), and it's not encrypted. Piping `dump` through file-based
  576: encryption tools like `gpg` can be one way of addressing this issue, but make
  577: sure you have all the keys and tools you need to decrypt it to `restore` after
  578: a disaster.
  579: 
  580: Like any form of software encryption, the `cgd` key stays in kernel memory while
  581: the device is configured, and may be accessible to privileged programs and
  582: users, such as `/dev/kmem` grovellers. Taking other system security steps, such
  583: as running with elevated securelevel, is highly recommended.
  584: 
  585: Once the `cgd` volumes are mounted as normal filesystems, their contents are
  586: accessible like any other file. Take care of file permissions and ensure your
  587: running system is protected against application and network security attack.
  588: 
  589: Avoid using suspend/resume, especially for laptops with a BIOS suspend-to-disk
  590: function. If an attacker can resume your laptop with the key still in memory, or
  591: read it from the suspend-to-disk memory image on the hard disk later, the whole
  592: point of using `cgd` is lost.
  593: 
  594: ## Further Reading
  595: 
  596: The following resources contain more information on CGD:
  597: 
  598: ### Bibliography
  599: 
  600:  * [smackie-cgd]: *[NetBSD CGD Setup](http://www.bsdguides.org/guides/netbsd/misc/cgd_setup.php)*. Stuart Mackie.
  601:  * [nycbug-cgd]: *[I want my cgd](http://genoverly.com/articles/view/5/) aka: I want an encrypted pseudo-device on my laptop*.
  602:  * [elric-cgd]: *The original paper on [The CryptoGraphic Disk Driver](http://www.imrryr.org/~elric/cgd/cgd.pdf)*. Roland Dowdeswell and John Ioannidis.
  603:  * [biancuzzi-cgd]: *[Inside NetBSD's CGD](http://onlamp.com/pub/a/bsd/2005/12/21/netbsd_cgd.html) - an interview with CGD creator Roland Dowdeswell*. Biancuzzi Federico.
  604:  * [hubertf-cgd]: *[CryptoGraphicFile (CGF)](http://www.feyrer.de/NetBSD/blog.html/nb_20060823_2311.html), or how to keep sensitive data on your laptop*. Feyrer Hubert.
  605: 

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb