Encryption

Published on January 2017 | Categories: Documents | Downloads: 28 | Comments: 0 | Views: 520
of 10
Download PDF   Embed   Report

Comments

Content

A article outlining the many flaws people are unaware of when using full disk encryption and how to fix them.
Introduction -------------Full disk encryption is becoming a very popular method of protecting ones self from data theft nowadays, especially among linux users. What someone might not know is that setting up secure full disk encryption isn't as easy as selecting it from a linux installer or choosing the option in some A article outlining the many flaws people are unaware of when using full disk encryption and how to fix them. Introduction -------------Full disk encryption is becoming a very popular method of protecting ones self from data theft nowadays, especially among linux users. What someone might not know is that setting up secure full disk encryption isn't as easy as selecting it from a linux installer or choosing the option in some software program. If you use full disk encryption, you could be, and most likely are, vunerable to a multitude of attacks that could render your efforts useless. Your probably at risk if: - Your kernel isnt encrypted and is on your local drive (the standard option for most 'full disk encryption' solutions) - You have a firewire port - You leave your computer unattended at any time its on, or directly after its been shut down This tutorial will show you how these are threats and how to deal with each one of them. I will explain how to solve these problems only on linux, but it should be adaptable to any *nix OS. Firstly, I'd like to make a note. You may think "Well it takes a 'Uber hacker' to pull off those tactics, why should I worry about that?". Well, if your wasting all that computing power to encrypt and unencrypt the data as its written and read from your harddrive just to hide porn from your girlfriend, you might want to look into different methods. Full disk encryption is made for the people who have something to hide from other people who are determined enough to learn how to use those tactics and exploit the above encryption holes. If your hiding something from someone that doesnt have any computer smarts then maybe look into alternate methods such as: - Container Encryption - Encryption that is only on a single directory or file. - Password protection - Creating a password protected directory or file. The file isnt encrypted, but cant be accessed without a password or someone that would boot up a live linux distrobution and look at the files that way. - Permission Protection - Simply changing the permissions on a directory or file so nobody but the root (admin) user or you can access the file/directory. Now that I've cleared that up, lets move on :) Killer Kernel -------------The Kernel is the boss of the operating system. It controls which data goes where and what is allowed to do each thing. You could see it as the rules of the universe, and we are the programs. We

can only do what the rules allow us to do. We are limited by gravity, time, our need for food, etc. This godly kernel that is in full control of your computer, is sitting unencrypted on your harddisk. Thats right, there is absolutely zero encryption protection on this piece of software. Someone could walk right in while your computer is off, boot up the computer with a Live CD, and install their very own kernel to replace the old. So when you get home from work, turn on your computer, and enter your encryption code, the new kernel that you are not aware is there could have been modified to send your encryption key to the person who installed the modified kernel via the internet. Now that person has your code and with it access to all the data on your drive. So why not encrypt the kernel? Problem solved, right? Wrong. When you turn on your computer this is what happens: 1. Everything is powered up and the BIOS is started 2. Once the BIOS has done what it wants, it looks for a boot device, such as a CD, USB drive, or Harddrive. 3. Once a boot device that has a boot loader on it has been found, it hands control over to the boot loader. 4. The boot loader (such as GRUB, or LILO, or the Windows boot loader) then loads up the pregenerated list of kernels on the harddrive (or sometimes another boot device). 5. The boot loader loads the kernel its supposed to and hands over control. 6. The kernel sees the harddrive is encrypted and asks for a key. Once a correct one is given, it unencrypts the data and starts booting the OS. See how that works? If we encrypt the kernel, the boot loader would need to unencrypt the kernel, so the boot loader would have to ask for a key. But the bootloader would have to be unencryped, so someone could just as easily edit the boot loader to send them the key, as with the kernel. If we took even another step back and encrypted the Boot loader, the BIOS would have to be unencrypted and ask for the encryption key, and hence the BIOS could be edited. We could build encryption right into the hardware, which would effectively make it very difficult to bypass, but then everybody who bought the hardware would only be able to have one operating system that could not be changed. Imagine being stuck with Windows, or not being able to get rid of Linux if you wanted to install windows again (I cant see why you would want that, though). So obviously hardware companies are not going to do that just to make a few people happy but the rest really unhappy. Especially not when there is a way we can fix the problems ourselves. So how do you do that? I'll tell you :) "There is no security like physical security" What you have to do is make it so its impossible to edit the kernel. To do so, you have to keep the kernel on you at all times. No, I dont mean sticking your laptop up your shirt to go to work, I mean installing your kernel and boot loader onto a USB stick that you can carry around with you around your neck or in your pocket. Then, you know for sure that your kernel hasnt been edited because its been in your own sweaty clutches all day. If you were really paranoid, you might even keep it in a locked safe at night. Unfortunately, you will need a computer that can boot from USB. To enable this, you will have to access the BIOS on your computer and change the settings. The BIOS can be accessed usually just when the system starts up, it should say on the screen that there is a button you can press like F12 or ESC to enter settings. It depends on the computer manufacter and model, but its generally pretty straight forward. Once your in the BIOS, just set up USB to be the first boot device. It might not be called USB, it could be called external harddrive or something similar. If you need more explicit instructions, or your not sure if your system supports USB booting, just google around for instructions and im sure you'll find something. If not, it cant hurt to call the company. So now that you've gotten that set up you will of course need a USB drive. They dont need to be very big, 200MB should be more than enough.

Now comes installing Grub, the most common linux bootloader, on your USB stick. By far the easiest way would be to reinstall your operating system, and when doing so, specify your USB drive to be the partition that holds boot and the rest of your harddrive to be encrypted. If you don't want to reinstall your system, you can take the harder way and format your USB stick, copy /boot/ onto it, and manually install grub onto the USB stick. For this, you'll need to unmount /boot/, remount your USB stick in its place, edit /etc/fstab so the line that mounts /boot/ is commented out, and then, finally, run grub-install /dev/sdb (or whatever happens to be the name of your USB stick). That method can be quite complex to new linux users, so my recommendation is to install from scratch unless you know what your doing. There you go, your encrypted drives should now be as safe as possible from any attackers you may encounter. One thing I should point out though, is that alot of system updates (mainly kernel updates) need to modify the files on /boot/ to correctly perform the update. You should make sure that your USB stick is plugged in and mounted before you do any system updates. Firewire, oh sweet firewire :( ------------------------------Imagine for a second yourself in a coffee shop, or somewhere else thats public and you would bring your laptop to, drinking a cup of coffee and playing pacman on your laptop. While you're being an intense 70's gamer, someone just slipped a cord into the back of your computer and is downloading your encryption key. It takes less than a minute, and the only way you could tell is if you happened to be scanning your computer for abnormal activity at the time, or you caught the person with his cord jacked in. As far as I know, its full possible to perform this attack from a hand held device. Someone could sit down, start to talk to you, plug in a cable without you noticing, quickly get the key, and pull it out. What causes this is that firewire allows the two connected devices to access the others RAM directly, with no restrictions at all. So the device thats connected to your system could download everything thats in your RAM, including any passwords, SSH keys, sensitive files, and most importantly your encryption key. Sadly, the only way to really solve this is to completely disable firewire. This can be done from your BIOS sometimes, but just in case not, i'm going to show you a more software based way. What were going to do is blacklist the kernel module. Remember that kernel I was telling you about? It has things called 'modules' that are added into it so it can handle extra hardware on your system. These modules control things like your ethernet ports, USB ports, firewire ports, and much more. So what we have to do is completely cut off the firewire module from the kernel. The most common driver is ieee1394, however yours might be different. If it doesnt work, consider using the lsmod command to check your loaded modules. To disable the ieee1394 module, run one of these commands are root: If you run CentOS/Redhat/RHEL/Fedora: echo "alias 1394 off" >> /etc/modprobe.conf If you run Debian/Ubuntu: echo "blacklist ieee1394" >> /etc/modprobe.d/blacklist

Not that you needed to know, but...... -----------------------------------------For fun, lets talk about the most absolutely unlikely thing to happen: Someone walks into your

house, while you are on your computer that has perfect encryption set up, pushes you away from your desk, picks up your computer, drops it into a big cooler full of liquid nitrogen, leaves, and jumps into the back of a big black truck which proceeds to drive away with your system. Why, you ask? Liquid Nitrogen is cold, very cold. In fact, its -196C or -320F. That is enough to freeze virtually anything, including your RAM. When you start up your system and enter your encryption key, the key is needed again and again by your system throughout the time its turned on to unencrypt the data it reads and encrypt the data it writes. Were does it store this key? Obivously not the harddrive, since its too slow and you cant unencrypt something with a encrypted key :P Instead we use the RAM (Random Access Memory). If your not sure what this is, you will probably want to google it. Going back to the story, these people that now have your computer can now get the encryption key off of your RAM, since the key is litterally frozen into the RAM. Once they have the key, they can use it to unencrypt your harddrive and they have your data. This has happened before, but it was by the government and they need a warrent to perform such a intrusion of privacy. It also costs lots of money to do, and there is virtually no logical way to prevent it but to see it comming. What I would do, if I was expecting government agents to bust down my door (not that I am :P), is set up security cameras and be ready to pull the power plug, throw myself on top of the computer, then hope to buy myself enough time for the encryption key to be wiped from the RAM. That would probably work, assuming that I can stop a bunch of muscle bulging government agents from separating me and the computer for around a minute. Of course, its a little unorthadox to keep a microwave for the sole purpose of throwing harddrives in it unless your some super corrupt hacker who has broken into thousands of high importance government systems and stolen millions of dollars, and are already under suspicion. So you shouldn't worry about this one, its mainly for informational purposes. ;) Also, another way this could be executed is if you leave your system alone after its been shut down. RAM has a flaw (well, its only considered a flaw when it comes to encryption) where information that stays in the same spot of the RAM may become 'imprinted' into the RAM. So that even after the system looses power, it may take up to 10 minutes for the information to leave the RAM. Fortunately, there is a workaround that is used commonly now that will move all the information that has been gotten from a encrypted source around periodically to prevent it from being imprinted in the RAM too long. This effectively cuts the waiting time down from 10 or so minutes to 1 minute. Conclusion -----------Well, there you go. You have learnt all I have to teach you about encryption, and hopefully put the knowledge to the best of use. Who knows, maybe I just helped someone get interested into a career in cryptography :) I grabbed this article from my website at: www.stealth-x.com/articles/the-problems-with-full-diskencryption.php. So, if your under the impression it was plagiarized, please don't be :) software program. If you use full disk encryption, you could be, and most likely are, vunerable to a multitude of attacks that could render your efforts useless. Your probably at risk if: - Your kernel isnt encrypted and is on your local drive (the standard option for most 'full disk encryption' solutions) - You have a firewire port - You leave your computer unattended at any time its on, or directly after its been shut down This tutorial will show you how these are threats and how to deal with each one of them. I will explain how to solve these problems only on linux, but it should be adaptable to any *nix OS.

Firstly, I'd like to make a note. You may think "Well it takes a 'Uber hacker' to pull off those tactics, why should I worry about that?". Well, if your wasting all that computing power to encrypt and unencrypt the data as its written and read from your harddrive just to hide porn from your girlfriend, you might want to look into different methods. Full disk encryption is made for the people who have something to hide from other people who are determined enough to learn how to use those tactics and exploit the above encryption holes. If your hiding something from someone that doesnt have any computer smarts then maybe look into alternate methods such as: - Container Encryption - Encryption that is only on a single directory or file. - Password protection - Creating a password protected directory or file. The file isnt encrypted, but cant be accessed without a password or someone that would boot up a live linux distrobution and look at the files that way. - Permission Protection - Simply changing the permissions on a directory or file so nobody but the root (admin) user or you can access the file/directory. Now that I've cleared that up, lets move on :) Killer Kernel -------------The Kernel is the boss of the operating system. It controls which data goes where and what is allowed to do each thing. You could see it as the rules of the universe, and we are the programs. We can only do what the rules allow us to do. We are limited by gravity, time, our need for food, etc. This godly kernel that is in full control of your computer, is sitting unencrypted on your harddisk. Thats right, there is absolutely zero encryption protection on this piece of software. Someone could walk right in while your computer is off, boot up the computer with a Live CD, and install their very own kernel to replace the old. So when you get home from work, turn on your computer, and enter your encryption code, the new kernel that you are not aware is there could have been modified to send your encryption key to the person who installed the modified kernel via the internet. Now that person has your code and with it access to all the data on your drive. So why not encrypt the kernel? Problem solved, right? Wrong. When you turn on your computer this is what happens: 1. Everything is powered up and the BIOS is started 2. Once the BIOS has done what it wants, it looks for a boot device, such as a CD, USB drive, or Harddrive. 3. Once a boot device that has a boot loader on it has been found, it hands control over to the boot loader. 4. The boot loader (such as GRUB, or LILO, or the Windows boot loader) then loads up the pregenerated list of kernels on the harddrive (or sometimes another boot device). 5. The boot loader loads the kernel its supposed to and hands over control. 6. The kernel sees the harddrive is encrypted and asks for a key. Once a correct one is given, it unencrypts the data and starts booting the OS. See how that works? If we encrypt the kernel, the boot loader would need to unencrypt the kernel, so the boot loader would have to ask for a key. But the bootloader would have to be unencryped, so someone could just as easily edit the boot loader to send them the key, as with the kernel. If we took even another step back and encrypted the Boot loader, the BIOS would have to be unencrypted and ask for the encryption key, and hence the BIOS could be edited. We could build encryption right into the hardware, which would effectively make it very difficult to bypass, but then everybody who bought the hardware would only be able to have one operating system that could not be changed.

Imagine being stuck with Windows, or not being able to get rid of Linux if you wanted to install windows again (I cant see why you would want that, though). So obviously hardware companies are not going to do that just to make a few people happy but the rest really unhappy. Especially not when there is a way we can fix the problems ourselves. So how do you do that? I'll tell you :) "There is no security like physical security" What you have to do is make it so its impossible to edit the kernel. To do so, you have to keep the kernel on you at all times. No, I dont mean sticking your laptop up your shirt to go to work, I mean installing your kernel and boot loader onto a USB stick that you can carry around with you around your neck or in your pocket. Then, you know for sure that your kernel hasnt been edited because its been in your own sweaty clutches all day. If you were really paranoid, you might even keep it in a locked safe at night. Unfortunately, you will need a computer that can boot from USB. To enable this, you will have to access the BIOS on your computer and change the settings. The BIOS can be accessed usually just when the system starts up, it should say on the screen that there is a button you can press like F12 or ESC to enter settings. It depends on the computer manufacter and model, but its generally pretty straight forward. Once your in the BIOS, just set up USB to be the first boot device. It might not be called USB, it could be called external harddrive or something similar. If you need more explicit instructions, or your not sure if your system supports USB booting, just google around for instructions and im sure you'll find something. If not, it cant hurt to call the company. So now that you've gotten that set up you will of course need a USB drive. They dont need to be very big, 200MB should be more than enough. Now comes installing Grub, the most common linux bootloader, on your USB stick. By far the easiest way would be to reinstall your operating system, and when doing so, specify your USB drive to be the partition that holds boot and the rest of your harddrive to be encrypted. If you don't want to reinstall your system, you can take the harder way and format your USB stick, copy /boot/ onto it, and manually install grub onto the USB stick. For this, you'll need to unmount /boot/, remount your USB stick in its place, edit /etc/fstab so the line that mounts /boot/ is commented out, and then, finally, run grub-install /dev/sdb (or whatever happens to be the name of your USB stick). That method can be quite complex to new linux users, so my recommendation is to install from scratch unless you know what your doing. There you go, your encrypted drives should now be as safe as possible from any attackers you may encounter. One thing I should point out though, is that alot of system updates (mainly kernel updates) need to modify the files on /boot/ to correctly perform the update. You should make sure that your USB stick is plugged in and mounted before you do any system updates. Firewire, oh sweet firewire :( ------------------------------Imagine for a second yourself in a coffee shop, or somewhere else thats public and you would bring your laptop to, drinking a cup of coffee and playing pacman on your laptop. While you're being an intense 70's gamer, someone just slipped a cord into the back of your computer and is downloading your encryption key. It takes less than a minute, and the only way you could tell is if you happened to be scanning your computer for abnormal activity at the time, or you caught the person with his cord jacked in. As far as I know, its full possible to perform this attack from a hand held device. Someone could sit down, start to talk to you, plug in a cable without you noticing, quickly get the key, and pull it out. What causes this is that firewire allows the two connected devices to access the others RAM directly, with no restrictions at all. So the device thats connected to your system could download everything thats in your RAM, including any passwords, SSH keys, sensitive files, and most importantly your encryption key. Sadly, the only way to really solve this is to completely disable firewire. This can be done from your BIOS sometimes, but just in case not, i'm going to

show you a more software based way. What were going to do is blacklist the kernel module. Remember that kernel I was telling you about? It has things called 'modules' that are added into it so it can handle extra hardware on your system. These modules control things like your ethernet ports, USB ports, firewire ports, and much more. So what we have to do is completely cut off the firewire module from the kernel. The most common driver is ieee1394, however yours might be different. If it doesnt work, consider using the lsmod command to check your loaded modules. To disable the ieee1394 module, run one of these commands are root: If you run CentOS/Redhat/RHEL/Fedora: echo "alias 1394 off" >> /etc/modprobe.conf If you run Debian/Ubuntu: echo "blacklist ieee1394" >> /etc/modprobe.d/blacklist

Not that you needed to know, but...... -----------------------------------------For fun, lets talk about the most absolutely unlikely thing to happen: Someone walks into your house, while you are on your computer that has perfect encryption set up, pushes you away from your desk, picks up your computer, drops it into a big cooler full of liquid nitrogen, leaves, and jumps into the back of a big black truck which proceeds to drive away with your system. Why, you ask? Liquid Nitrogen is cold, very cold. In fact, its -196C or -320F. That is enough to freeze virtually anything, including your RAM. When you start up your system and enter your encryption key, the key is needed again and again by your system throughout the time its turned on to unencrypt the data it reads and encrypt the data it writes. Were does it store this key? Obivously not the harddrive, since its too slow and you cant unencrypt something with a encrypted key :P Instead we use the RAM (Random Access Memory). If your not sure what this is, you will probably want to google it. Going back to the story, these people that now have your computer can now get the encryption key off of your RAM, since the key is litterally frozen into the RAM. Once they have the key, they can use it to unencrypt your harddrive and they have your data. This has happened before, but it was by the government and they need a warrent to perform such a intrusion of privacy. It also costs lots of money to do, and there is virtually no logical way to prevent it but to see it comming. What I would do, if I was expecting government agents to bust down my door (not that I am :P), is set up security cameras and be ready to pull the power plug, throw myself on top of the computer, then hope to buy myself enough time for the encryption key to be wiped from the RAM. That would probably work, assuming that I can stop a bunch of muscle bulging government agents from separating me and the computer for around a minute. Of course, its a little unorthadox to keep a microwave for the sole purpose of throwing harddrives in it unless your some super corrupt hacker who has broken into thousands of high importance government systems and stolen millions of dollars, and are already under suspicion. So you shouldn't worry about this one, its mainly for informational purposes. ;) Also, another way this could be executed is if you leave your system alone after its been shut down. RAM has a flaw (well, its only considered a flaw when it comes to encryption) where information that stays in the same spot of the RAM may become 'imprinted' into the RAM. So that even after the system looses power, it may take up to 10 minutes for the information to leave the RAM. Fortunately, there is a workaround that is used commonly now that will move all the information that has been gotten from a encrypted source around periodically to prevent it from being imprinted

in the RAM too long. This effectively cuts the waiting time down from 10 or so minutes to 1 minute. Conclusion -----------Well, there you go. You have learnt all I have to teach you about encryption, and hopefully put the knowledge to the best of use. Who knows, maybe I just helped someone get interested into a career in cryptography :) I grabbed this article from my website at: www.stealth-x.com/articles/the-problems-with-full-diskencryption.php. So, if your under the impression it was plagiarized, please don't be :)

Researchers uncover encryption flaws Encryption researchers have discovered that mathematical functions embedded in common security applications have previously undetected weaknesses. Thursday, it was announced that French computer scientist Antoine Joux uncovered a flaw in a popular algorithm called MD5, often used with digital signatures. Then four Chinese researchers released a paper on how to circumvent a second algorithm, SHA-0, according to CNET News.com. While their results are preliminary, these discoveries could eventually make it easier for intruders to insert undetectable back doors into computer code or to forge an electronic signature unless a different, more secure algorithm is used. Another announcement at the Crypto 2004 conference in Santa Barbara, Calif. Eli Biham and Rafi Chen, researchers at the Israel Institute of Technology, originally were scheduled to present a paper identifying ways to assail the security in the SHA-0 "Secure Hash Algorithm," whic...

Although encryption provides voice privacy and data protection, without effective key management, a number of security risks associated with the integrity and confidentiality of encryption keys are introduced. Because encryption technology is somewhat new to public safety personnel, the majority of public safety agencies have not established any form of key management processes. The following describes security issues and concerns raised as a result of the increased use of encryption among radio users and the operational difficulties of implementing proper key management. 4.1 Manual Rekeying Method In the multiuser environment of the public safety community, it is difficult to distribute encryption keys efficiently and effectively. The results of risk assessments performed recently for design-stage and operational LMR systems provide anecdotal evidence that state and local public safety agencies use the manual rekeying method. In cases where encryption is used, to permit their subscriber units to be manually rekeyed, radio users must bring the radios to a designated location for a physical connection to the key loader. This method is very cumbersome and manpower intensive. As a result, keys are not changed regularly or in some cases not used. Therefore, procedural and security problems inherent in the manual rekeying method occur. Discussions with federal radio managers indicate the same reliance on, and issues with, manual rekeying. Federal agencies manage these issues often by bringing key loaders to radio users (e.g., at command centers) to facilitate rekeying. A key used to encrypt radio communications has a lifetime. Each time a key is used, it

generates a ciphertext. Using the same key for a long period allows an attacker to have many ciphertexts available, which can make the key easier to break. Radio communications encrypted with keys that have not been changed for long periods of time are vulnerable to the threat of unauthorized interception using the technical advances in decoding technology. 4.2 Interoperability Digital technology and the development of technical standards specified in TIA/EIA 102 (Project 25) enhance interconnectivity among local, state, federal and tribal public safety agencies. While interoperability provides greater benefits among public safety officials, it also raises new security issues related to the value of the shared information, level of encryption type, and responsibilities for security. Each public safety agency has its own specific operational requirements and environment. Therefore, key management procedures that may be suitable to one environment may not be appropriate for other agencies’ environments. Most public safety agencies have established mutual-aid agreements with other agencies. If the other agencies do not have compatible radio systems and the same type of encryption, sharing encrypted radio transmissions might not be feasible. When different types of voice Security Issues Report: Encryption Key Management for Public Safety Radio Systems 9 October 2001 privacy encryption are used on radio transmissions, dual transition will prevent efficient interoperable mutual-aid operations. Protected interoperability is possible when public safety officers from different agencies use a common key to perform different functions. However, this method has weaknesses on two fronts: keying material is not changed frequently, and not all radios support multi encryption keys. For these reasons, protected mutual-aid operations are difficult without some participants rekeying their radios.4 To provide effective protected interoperable communications, better key management processes that address these two matters must be considered and established. 4.3 Insecure Storage of Encryption Keys In general, encryption keys are stored on electronic media (e.g., diskettes or tapes) before or after key loading into KVLs. These media must be protected from unauthorized access with a proper key storage device (e.g., vault, safe, etc.) in a protected environment, and the keys should be stored in an encrypted form on the media. In particular, used keys should be stored in KMCs/KMFs during their cryptoperiod until they are deleted automatically or manually. Stringent access controls must be in place through user identification and authentication methods (e.g., passwords, biometrics, or tokens) and proper privilege assignment. However, few public safety agencies have developed comprehensive computer security-related policies. Therefore, no requirements have been established for using stringent password constraints even though the systems used as KMCs/KMFs provide security features that can be configured to enforce these constraints. Unless stringent access controls are used, no assurance can be provided that keys cannot be compromised by internal and external threats. Once unauthorized personnel pass through the physical barriers, any key-related information stored in electronic media and computers could be easily compromised. 4.4 Lack of Training Materials As public safety agencies begin to adapt to the new environment of using encryption more often, roles and responsibilities of encryption operators (i.e., crypto-custodians) who handle and maintain keys should be defined. Without roles and responsibilities being defined and assigned officially, the custodians can not be fully aware of the scope of their roles and can not have the positional authority necessary to perform these roles sufficiently well. Additionally, training programs for radio users should be established throughout public safety agencies.

Custodians without specific training for handling keying materials (or keys) could mishandle keys or keying materials. Specific procedures should also be available to radio users to follow in emergency situations or for handling radios with encryption capability while unattended. 4.5 Lost or Stolen Radios with Encryption In manual rekeying systems no mechanisms are available to disable keys remotely (i.e., over-the-air) if radios with encryption are lost or stolen. Key revocation must be timely and reliable; otherwise, unauthorized people could compromise radios and confuse officers. The key fill devices should have physical security mechanisms to protect the contents of the cryptographic module from unauthorized physical access (e.g., by employing tamper-evident mechanisms). If the key fill devices (specifically, the removable covers) are accessed, all encryption keys contained in the cryptographic module should be erased. This process is known as “zeroizing” the key. 4.6 Unspecified Policy and Guidelines The security issues addressed above all stem from unspecified guidelines on encryption key management. Because public safety officers focus on obtaining efficient and effective operational functions, adding on security or developing administrative guidelines are often afterthoughts. Many public safety agencies have not documented the information necessary to compile a complete set of specifications and requirements on key generation, storage, entry, key destruction, key changes, physical security mechanisms, and operating system security. Therefore, there is no assurance that encryption used for radio communications is compliant with Federal Information Processing Standard (FIPS) 140-2, Security Requirements for Cryptographic Modules. 4.7 Comprehensive Key Management Procedures The complexity of key management, which documents detailed instructions, methods, and network connectivity, discourages agencies from establishing comprehensive key management procedures. Thus, cost-effective solutions should be examined that can then be used by agencies with either a small network or a large network to efficiently manage encryption keys without endangering key security. 4.8 Improper Physical Security Controls The lack of physical security controls for areas where keying materials are housed (e.g., rooms, communications centers, and maintenance facilities) seriously affects key security. Adequate physical security controls are the first protection for keying materials. Although radio managers are aware of the importance of physical security controls, resources (e.g., funding and personnel) are required to implement and enhance physical security controls suitable to their particular environments.

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close