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