GSM networks in the US and Europe use the A5/1 stream cipher to ensure cellular calls cannot be listened into by unauthorized parties monitoring radio traffic. However, the guarantee of privacy is no longer ensured. New attack techniques were unveiled at the Hacking at Random conference in The Netherlends which would allow an attacker to decrypt cellular calls made over a GSM network. The attacker only needs the new software and about $500 in radio monitoring equipment. The AS5/1 cipher has been criticized for many years, but this is one of the first publicly available exploits to demonstrate the weaknesses first hand.


The presentation is here.
The A5/1 cracking project homepage is here.

GSM is used by many major cellular providers such as AT&T and T-Mobile (see GSM Coverage Map). The main alternative to GSM network is CDMA which is used by providers such as Verizon, Alltel and US Cellular (see CDMA World Map).

Impacts?
The ability to decrypt A5/1 encryption would enable an attacker to listen in to all cellular communications made over a GSM network. To execute the attack the attacker would need to be close enough to the target to monitor the radio waves emitted from the phone. However, this isn't much of a restriction since the radio waves can be picked up from quite some distance.

This attack should raise serious concerns about the sensitivity of information exchanged over cell phones. An attacker with this equipment situated near a major corporate office or within a large city could easily glean very sensitive data from cellular voice calls.

Regarding data exchanged over cellular phones (e.g. 3G or EDGE), this shouldn't really have any impact. All sensitive data should already be configured to use SSL/TLS or VPN for protection during transmission. Therefore, the attacker could break the A5/1 cipher, but they would only see encrypted data being exchanged. However, all data that is exchanged using clear text protocols (HTTP, telnet, ftp, etc) would be visible to the attacker. This is not much of a concern since there should not be any expectation of confidentiality when using a clear text protocol anyway.

About the attack
The attack leverages rainbow tables for a Time-Memory Trade-Off based attack. The A5/1 cracking project is enabling volunteers to help develop the rainbow tables for the A5/1 cipher and distributing the generated tables over bittorrent. Clever adaptations were made to the rainbow table generation to minimize the number of tables that were needed and thus dramatically reduced the required processing efforts.

This is a guest post by Michael Coates, a senior application security consultant with extensive experience in application security, security code review and penetration assessments. He has conducted numerous security assessments for financial, enterprise and cellular customers world-wide.

The original text is published on ...Application Security...

Talkback and comments are most welcome

Related posts
Google Voice - No Privacy Remains?

Alternate Data Streams is a feature of the NTFS filesystem. In essence they were created to provide compatibility with HFS, or the old Macintosh Hierarchical File System. The way that the Macintosh's file system works is that they will use both data and resource forks to store their contents. The data fork is for the contents of the document while the resource fork is to identify file type and other pertinent details.



How do you create an ADS? Wonderfully easy: All you need to do is have the two files, and then send the file to be hidden to the ADS of the host file with a simple type command:

type file_to_be_hidden> host_file:name_of_file_to_be_hidden

The most frequent use of ADS for malicious purposes is to conceal the executable of a trojan/rootkit as an Alternate Data Stream (ADS) to a perfectly safe file. For instance, once an attacker penetrates a Windows system, he can easily hide the malicious payload for further access into an executable which is fairly frequently used - like Calculator.

Alternate Data Streams may also be interesting as a mechanism to hide and transport information out of an organization:
Once you include an ADS into a file, there is no visible change in filesize of the host file, only the modified date is changed. This makes it quite difficult to detect the Alternate Streamed file. Also, the ADS file does not change the MD5 hash of the original file, which may prevent systems which control file modification through hashing from detecting the hidden file. Here is an example:

C:\Users\user\Desktop>md5sum test.txt
d41d8cd98f00b204e9800998ecf8427e *test.txt

C:\Users\user\Desktop>type image.jpg>test.txt:image.jpg

C:\Users\user\Desktop>md5sum test.txt
d41d8cd98f00b204e9800998ecf8427e *test.txt

One would think that this method of information hiding is great to transfer any amount of information with an inconspicuous carrier file being sent over a network. But there is a catch: most data carriers will ignore the Alternate Data Stream, and here is the summary list:

• Zip, RAR or ARJ will simply compress the host file and disregard the ADS
  
• MIME and Base64 encoding (e-mail) will ignore the ADS entirely
• FAT32 (mostly used on USB flash drives) will loose the ADS since it's not supported.
• Steganography programs will read the bytes of the host file and stop at the EOF
• FTP and HTTP transfer ignores ADS entirely
• Recording the
  

But all is not lost. There are still ways to transfer data with ADS:

• Transferring the host file over SMB network to an NTFS target retains the ADS hidden file
  
• Copying the host file to an NTFS file system transfers the ADS hidden file

So the information theft scenario with ADS is mostly available to employees or trusted persons:

1. The malicious user will create a legal host file and ADS a file with information to be stolen.
   
2. He will convince the manager to take the legal file home to work on over the weekend.
   
3. Upon the manager's request, even if USB drives are restricted, IT will copy the file over SMB and onto the employee's USB - which is sparkling clean and conveniently formatted with NTFS.
   
4. All logs of the transfer will contain the transfer of the original approved file to the USB

What will you do in such a scenario? Talkback is most welcome!

Related posts
Be Aware of Security Risks of USB Flash Drives
5 biggest mistakes of information security

The importance of a good encryption algorithm is essential to functional security. And yet there are a lot of misguided initiatives to use an 'internal', 'trusted' and 'secret' algorithm. Obscurity IS NOT Security and an algorithm that hasn't passed external scrutiny may be fundamentally flawed. If you go down that road you may even find your encryptions hacked by non-programmers.



Here is a tutorial on how easy it is to crack an encryption that is not properly designed.
For this tutorial, We are going to work with a really simple and weak algorithm - XECryption.

Here is a narrative summary of the algorithm:

• The password the user chose is first used to produce a number by adding the ASCII value of every character in the password to produce one large total. This number is used as the encryption key.
• The message is encrypted by adding the password key is added to the ASCII value of each letter in the message, then it is divided by three. A random number between -10 and 10 is added to this new number. This becomes the first number in the series, and is repeated to produce the second number. The third number is the difference between the first two final numbers and the original ASCII value plus the password key. At the end, every letter in the encrypted message takes on the following format: ".193.144.164".
• When decrypting, the password key is found in the same way that it's encrypted. Each triplet is added together, and then the password key is subtracted. This is the ASCII value of the letter.

So in summary, an XECryption encrypted message represents each letter in number triplets. Here is a sample XECryption encrypted message for your exercise.

Most readers have already noticed that there are a lot of flaws to the algorithm. Here are some which we will use:

1. There are multiple decryption passwords - there are a lot of combinations of characters that will produce the same number which is used to create the encrypted message. In essence
   
2. Also,the encryption number/key is contained within the message.
3. It is extremely easy to bruteforce this algorithm.

Here is how to approach this crack, and you won't even need to program anything:

1. First, we need to remember that each total of the triplets contains the encryption number, and since it needs to be subtracted from the total, the resulting number needs to be positive. So your password is contained even in the lowest total of any triplet in the message.
2. Once you find the lowest triplet total, you can just attempt all numbers starting from the lowest total down to zero as a possible encryption number - in essence, just bruteforce the text.
3. If you use a program to do the bruteforcing, you need to program a logic which will be able to identify that the bruteforced result is the real solution. This is usually done by counting how many of the bruteforce calculated ASCII codes are codes for letters, numbers and punctuation marks. If the percentage is large, it is a possible solution.
4. If you use Excel, the pattern matching will be done by your brain - a human can easily identify words and discover the solution.
5. To utilize this approach, simply place the encrypted text into an excel sheet, and create sums of every three numbers. These numbers are the triplet totals that need to be decrypted.
   
6. Place the triplet totals sequence on row 1 of a sheet, and on column 1 find the minimum total of the sequence. Starting from this minimum simply fill the rows in column 1 with every number from the minimum down to 1
7. Then in the cells from row 2 and in all columns which have triplet total in row 1 use the following function - CHAR(Row1,ColumnX - RowX,Column1).
8. Start reading the text in the rows and find your solution. Here is an excel file example of a decryption - the word 'hello' encrypted with a password 'hi'
   

Once you discover your most probable solution, just use the encryption number on the start of the row and the encrypted message on this site to check.

So, go ahead and try the described methodology - and post the identified source (author and book) of the encrypted text.
Every successful identification gets an honorable mention and a link in the followup article!

Talkback and comments are most welcome

Related posts
TrueCrypt Full Disk Encryption Review
5 rules to Protecting Information on your Laptop
Windows 7 Full Disk Encryption with Truecrypt
Tutorial - Hidden Operating System with Truecrypt
Tutorial - A Poor Man's Secure USB
Hardware Security Module for Dummies

After the TrueCrypt Full Disk Encryption Review and the 5 rules to Protecting Information on your Laptop, we are following up with a practical test of full disk encryption of Windows 7.

Shortinfosec is a great promoter of full disk encryption of laptop hard drives, and we have been using Windows 7 for several months now. On 21 Oct 2009, Truecrypt published the version 6.3 which has full support for Windows 7. Of course, why go for an open source product instead of the native BitLocker? Well, Microsoft with it's product strategy includes BitLocker only in Ultimate and Enterprise versions of Windows 7!

Can someone say 'huge security misstep' - especially for the Windows 7 Pro users?

Encryption
Naturally, Shortinfosec started with a full disk encryption test on a laptop. The laptop has the following configuration.

• 2.1 Ghz Core2Duo CPU
• 3 GB of RAM
  
• 320 GB of disk drive
• NVIDIA graphics
• Windows 7 Pro 32 bit operating system

The process is the same as already described in TrueCrypt Full Disk Encryption Review. The installation of the TrueCrypt is so generic that even the most inexperienced users should have no problems whatsoever.

The actual encryption is lasts between 6-7 hours. After it finishes, you have an encrypted system drive. If absolutely necessary, you may even use the computer while the drive is being encrypted, but you won't be very productive.

Performance test
The laptop had a passmark test run before and after the encryption. We focused on CPU and HDD performance, since these areas are impacted when using an encrypted file system.

The test results are presented on the following screenshots. The overall performance of the Test Laptop is marginally better for the non-encrypted disk clone. The disk drive is most impacted on the random read/write test.

The results in red color are before the encryption
The results in green color are after the encryption



Conclusion
Encrypting the entire hard drive of Windows 7 may not seem to be a natural choice, but the product strategy of MS opens up an opportunity for products like Truecrypt.

Encrypting the entire hard drive will cause performance reduction of the disk subsystem, but the performance reduction on our system is so minute that it is just ignored by everyone.

Talkback and comments are most welcome

Related posts

Cracking a TrueCrypt Container
TrueCrypt Full Disk Encryption Review
Tutorial - Hidden Operating System with Truecrypt
Tutorial - A Poor Man's Secure USB

Starting from version 6, Truecrypt boasts an interesting function- creation of a hidden operating system. With this article we walk through the process of creating the hidden OS and analyze the possible uses of such a solution.

The concept
The basic idea of the hidden OS is to have two operating systems on the PC

• the decoy (the visible one) - an OS that is visible to an outsider and actually contains no sensitive data, so it can be safely opened up to external personnel (investigators, customs officers etc)
• the outer volume - a container partition where the hidden OS resides. It can contain some decoy confidential files. The idea of the outer volume is to explain the existence of a seemingly unformatted partition, since it can be mounted from within the decoy OS to show the decoy confidential files.
  
• the hidden one - non-existent at first glance and created within an encrypted partition, which can hold sensitive data and should not be reported to external personnel.

The process
The process of creating the hidden OS is quite simple but takes time

1. Create an outer container of the hidden OS
2. Create an inner container and image the running OS into a hidden OS
3. Re-create the visible (decoy) OS
   

A prerequisite to the process is having an empty partition (must be the one immediately behind the system system) at least 5% larger then the system partition.


After that, it boils down to following the on-screen instructions and waiting (the encryption and copying can take some time)




The final element of the process is the destruction of the original OS partition - don't worry, it has been entirely copied to the hidden volume. After that comes the only manual part of the process - the user must install the decoy operating system from scratch, and encrypt it's partition.



Usability of the solution
Apart from proving the concept, it does work without any glitches, how effective is it?

1. Using a hidden OS with plausible deniability- The entire concept as presented within the TrueCrypt software should enable the user to claim that he has divulged all passwords for all operating systems/partitions on the computer. This is disputable to say the least, since any analysis will show a second partition with seemingly random data on it, which is a nice giveaway that there is something hidden there. In most cases where a person is under investigation the investigators will press to gain access to any partitions on the computer.
• This hiding methodology is public, so even if the existence of the hidden OS is not divulged, the investigators can destroy the hidden OS by filling the outer container with dummy files just to be on the safe side.
• 
2. Using a hidden OS as a dual function computer - a much more useful case of the Truecrypt hidden OS, it can be used to create a mobile computer. The hidden OS should be used for corporate functions. For field use or use in an insecure environment, the decoy OS should be used, which cannot access the encrypted volume and which should not have any corporate or confidential data on it.
   

Talkback and comments are most welcome

Related posts
Cracking a TrueCrypt Container
TrueCrypt Full Disk Encryption Review
Tutorial - A Poor Man's Secure USB
Creating secure CD/DVD media for transport usingTruecrypt

This week i tried to open an old TrueCrypt container. It turned out that i had forgotten the password. So I endeavored into the realm cracking the TrueCrypt container. Here are my experiences

The problem
I have a TrueCrypt container in which i hold my personal documents. The container is created with TrueCrypt 6.1a. Since i haven't been using the documents for a while, the password slipped from my mind. I a moment of desperation I tried to crack the password.

The preparation
To automate the process, I used the true.crypt.brute tool in version 1.9b. It is a very straightforward tool to use, but it has one drawback - it tries to crack based only on a pregenerated wordlist. That means that you need to generate your possible passwords list and let it rip.
First, i created a simple encrypted volume with a 2 character password to check the software.


It went through 819 passwords within 45 seconds and decrypted the password. This would mean that the brute force crack would run through around 64800 passwords per hour.


For a wordlist generator I used the old but excellent WG

Fist attempt and disappointment
If the password was in the interval between 2 and 4 characters and it contained only uppercase and lowercase alphabet and numbers, that means that you have 6,377,500 passwords to go through. The worst case scenario for a 4 character password is a bruteforce crack of 98 hours (4 days)

But, there is no 4 character password in a serious TrueCrypt container - especially mine.

Second attempt and disappointment
As luck was on my side, I was fairly certain of what the password was, only i couldn't tell which uppercase/lowercase letters i used and which numbers i added.
So i created a custom wordlist which included only the 13 letters contained in my password, and i set the password size between 16 and 18. I stopped the password generation at 33 million passwords. If i should run only those passwords, it would take me 21 days to go through them - and that's not a complete list!!!

A final attempt
As a final scenario i prepended the first part of the password - to which i was certain and left only 7 letters and 10 numbers to be padded. I distributed the workload on 4 machines, i cracked the password in 4 days.

Conclusion
The generic brute force attack on any target, including a TrueCrypt volume is extremely difficult to achieve since the time needed to try the passwords is very long. The only logical approach is to perform the 'due dilligence' of knowing the partial password before attacking the TrueCrypt volume.

Talkback and comments are most welcome

Related posts
Creating secure CD/DVD media for transport usingTruecrypt
TrueCrypt Full Disk Encryption Review
Tutorial - A Poor Man's Secure USB

A lot of companies think that they can make the full solution from scratch, including all technical mechanisms for security and encryption - including the hardware and the encryption algorithms and implement them in their solutions.

While the company strategists can have a field day of developing their own special market differentiation product, the enterprise customer should tread very lightly when evaluating solutions with custom encryption

The sales pitch
Naturally, when a salesperson gives his "latest and greatest solution" pitch, he'll be sure to include the possible benefits of having a custom encryption solution

1. It's much stronger encryption then any on the open market.
2. You get the best (insert technology buzz name) for keeping the encryption keys at a very affordable price.
   
3. Nobody knows our algorithm, so it's impossible to hack it.
   

The risks of choosing a custom solution
While the sales pitch may sound great, let's analyze the actual risks of having a custom encryption solution in your enterprise:

1. The custom encryption algorithm is not proven - the sales pitch of nobody knowing the algorithm is stupid. Security by obscurity does not work and that has been proven a lot of times. On the other hand, since nobody knows the algorithm, no independent test of the algorithm has been performed. For all that you know, the algorithm can have enough mathematical flaws to make breaking it a child's play.
2. The custom hardware for the encryption keys (if offered) is not tested according to well known standards - the latest and greatest in hardware means very little if not properly implemented. When talking about hardware for storing of encryption keys, there is a well known standard - FIPS 140-2. You should choose only hardware certified at FIPS 140-2 level 3 or 4
3. There is a high possibility of backdoors into the encryption - custom solutions can mean that the programmers have left in some backdoor. Having such backdoors is actually quite common, since it makes the programmer's life much easier in supporting the customer. Closed solutions mean that there is no open test to weed out these backdoors - and not too many vendors test their own solutions through independent contractors. Therefore, there is a risk of a disgruntled programmer using this back door to gain personal benefits, or simply to harm his former employer
   

So when someone offers you a solution with theirs own superstrong encryption - Just walk away

Talkback and comments are most welcome

Related posts
Hardware Security Module for Dummies

Information Risks when Branching Software Versions

3 rules to keep attention to detail in Software Development

8 Golden Rules of Change Management

Application security - too much function brings problems

Security risks and measures in software development

Security challenges in software development

Continuing the discussion about securing your backup media in transit, here is a tutorial on how to create a very secure media for public transport.

The target is to create a CD/DVD media that will contain a highly protected sensitive information. For this example, the sensitive information is a System State Backup of a Domain Controller, as per the example in http://www.shortinfosec.net/2008/06/6-steps-to-securing-your-backup-media.html

The process is as follows

1. Create a Truecrypt encrypted volume. Use dual encryption with different algorithms. The example uses Twofish-AES combination.
2. Name the volume file using a non-descript name, and protect the volume using a strong password.
3. Repeat steps 1 and 2 two more times, creating volumes of similar or same size as the first one, with similar file names.
4. The process in the example creates the files aws.ade, asq.dew and awd.adss
   
5. Mount one of the volumes (the example uses aws.ade volume) and save the sensitive file inside the volume.
6. Dismount the volume and burn all three files aws.ade, asq.dew and awd.adss to a CD
7. Place the CD inside a tamper-evident envelope with non-repeatable serial number and record the serial number.
8. Send the CD by courier. Call the recipient via a cell phone call and dictate the decrypting password and the file name containing the encrypted data.
   

Here is a video clip demonstrating the process of creation of secure media, using Truecrypt




Related posts
Risk of losing backup media - real example
8 Tips for Securing from the Security expert
TrueCrypt Full Disk Encryption Review
5 rules to Protecting Information on your Laptop

Talkback and comments are most welcome

My post about security about 6 steps to securing your backup media has sparked up comments that my example scenario is very grim and will not happen. Here is a real example of that grim scenario:

In 2005, LaSalle Bank Corp lost a tape containing confidential data of 2,000,000 residential mortgages. The tape listed mortgage customer names, accounts, payment histories and Social Security numbers. The tape was lost in the mail, while en route to a credit reporting bureau.

The tape was later recovered after missing for several weeks. Since the data was not encrypted, and there was no method to identify that the tape has been read or tampered with, LaSalle Bank Corp maintained high level of protection for customers from potential identity theft.
This has lead to undisclosed costs covered by the bank.

The bank has since abandoned transferring physical tapes to credit bureaus in favor of electronically sending encrypted files.

Here are several articles regarding this issue.
http://findarticles.com/p/articles/mi_hb5273/is_200512/ai_n20825812
http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1153797,00.html

Related articles
6 steps to securing your backup media
8 Tips for Securing from the Security expert
TrueCrypt Full Disk Encryption Review
5 rules to Protecting Information on your Laptop

Talkback and comments are most welcome

Spear phishing attack is a form of phishing attack which is aimed at targets with high authority and persons around them. By nature of their work, security procedures are disregarded or at least less respected in such circles, which can lead to significant security risks. Here is a quite realistic scenario for this attack.

The ShortInfosec Democorp CEO is away on business for the week. He has authorized his assistant to check his mail and handle responses as appropriate.
The ShortInfosec Personal Assistant reads an email from the chairman of the Democorp board to the CEO. The mail content is as follows:


The Personal Assistant sees that the mail is sent from the corporate e-mail address of Harry J and is formatted according to corporate standard. She knows that her boss will not read the e-mail for another 3 days.
So, she forwards the mail to marketing and sales, with the following text added:




Analysis

Within 15 minutes of receiving the original message, the directors of sales and marketing would have delegated the task to their subordinates and would have sent their documents to a Gmail address to which an unknown has access.
Here is what really happened:

1. The mail was originally fabricated by the attacker and sent from a open-relay SMTP, impersonating the President of the board
2. The names and official contact information of all relevant persons are available from the annual reports of Shortinfosec Democorp. If not, corporate e-mail format is standard and can be extrapolated by posing as a customer and exchanging several e-mails with other persons within Shortinfosec Democorp
3. The same method will be used to extrapolate the formatted signature at the end of the e-mail, as well as disclaimers or other standard corporate info contained in all e-mails.
4. An official conference agenda listed the Shortinfosec Democorp CEO as one of the speakers, so the attacker knows when he will be unavailable.
5. The WCI can be any relevant investment group, a name which can be identified from news clippings, or even invented - secretaries are not that much in the loop on large business decisions.

What should have happened

• The request to send confidential documents to a public email should have raised red flags.
• The Personal assistant should have called the President of the board to confirm the authenticity of the message.
• Also, she should have reported the mail as possible breach of procedures to the Information Security Officer and requested further instructions.
• Even if she disregarded all peculiarities of this email, the directors of sales and marketing and their subordinates should have reacted with a phonecall or alerted the Information Security Officer

In the real world, at the end of the day business comes first. So, the same material have gone to the Gmail account, but only after confirming that the president of the board requested it, and with maximum precautions

Result

An unknown person now has highly confidential corporate documents in his hands, which he can sell to the competition, publish, or extract information from them which will assist him to further his attacks.

Here are the controls that should be implemented to minimize risks of spear phishing

1. Implement e-mail digital signatures for all top management and key personnel, and set-up their laptops and PC's to automatically sign each sent message. Implement procedures that all unsigned messages received from these sources should be verified for authenticity
2. Perform regular training of all assistants and advisers to top management on Phishing and Social Engineering.
3. Perform regular but unannounced Social Engineering penetration testing on all assistants and advisers to top management, as well as all personnel handling highly confidential data
4. Educate top management with presenting results of penetration attacks to top to help them understand that breaching of instituted procedures can lead to severe security breaches - make this an exercise, not a power-point presentation
5. Advise all top management to accept and encourage the "when in doubt credibility of request, make a call" policy for their immediate subordinates, assistants and peers. Having a 1 minute phone call is much less fuss then a 100 page top secret report being leaked.
6. In case of real necessity to send such documents to public e-mail, provide fallback security procedures, for example: Send data as a Password protected PDF with a random password, wrapped in a different password protected rar file. Both passwords being communicated via another channel - sms or phone call directly to the president of the board
   

Related posts

Understanding Penetration Testing Methodology

TrueCrypt Full Disk Encryption Review

Hardware Security Module for Dummies

Personal Data Protection - Anonymizing John Doe

Talkback and comments are most welcome

My post 5 rules to Protecting Information on your Laptop finished with a recommendation to encrypt your hard drive.

Today I am following up with a review of the TrueCrypt tool for full Disk Encryption.

The review is performed on a VMware Virtual Machine, with the following configuration:

• 1.6 Ghz Core2 CPU, one CPU core active in the VM
• 256 MB of RAM allocated, fully allocated to RAM (No swap)
• 8 GB of disk drive simulated in a file
• USB
• No FDD
• Windows XP Pro SP2 operating system

As you can see, it is a relatively slow machine for today's standard of laptops, but this is on purpose, since the idea is to conclude whether this configuration is useable with an encrypted drive.

Encryption
The installation of the TrueCrypt is very straightforward, and even the most inexperienced users should have no problems whatsoever. Immediately after the installation, choose System->Encrypt system partition/drive.

Follow the instructions on the windows. Choose a very complex password since it cannot be changed. The software automatically creates a rescue (decrypt) CD Image, which you must burn on a blank CD media. Truecrypt WILL NOT continue with the actual encryption unless you present a burned CD with the decryption data.

NOTE: NEVER keep the rescue CD-ROM together with the laptop, since it will be used to decrypt the drive.
The actual encryption is lasts some 20-30 minutes. After it finishes, you have an encrypted system drive.

Performance test.
I have 2 identical clones of the Test Laptop, one with encrypted drive and one without.

I did a fast performance test with PassMark 6.1 Here are the conclusions:

As you can see, the test concludes that the overall performance of the Test Laptop is marginally better for the non-encrypted disk clone. However, on the disk drive read performance, the non-encrypted disk clone shows approximately 100% better results. (screenshots below)

PassMark Result for the Non-Encrypted Machine

PassMark Result for the Encrypted Machine


PassMark Disk Result for the Non-Encrypted Machine


PassMark Disk Result for the Encrypted Machine

Simulated theft of encrypted laptop

The encrypted laptop is "stolen" and following attempts to open it are performed

• Booting to Linux and attempting to access the file system - I booted the Helix forensics toolkit (knoppix) and attempted to mount the encrypted drive. The operating system could not identify the file system type. When i forced NTFS file system type, it refused to mount with a message of invalid I/O. The bit-for-bit DD copying still works however the actual copy is just as useless as the original.
• Booting to ERD Commander 2005 and attempting to access the file system - A simpler variant of the Helix attack. The ERD Commander didn't succeed in mounting the drive and complained about overlapping I/O
• Removing the drive and attempting to find strings in it - I tried this with the DD copy of the encrypted virtual drive. There were strings found but nothing useful.

Risks
After the initial review of the resulting encrypted drive, i came to the conclusion that the attacker will try to find a way around the encryption and to get the password or the decryption key. Here are the ways an attacker will attempt to obtain the information:

1. Social engineering to discover the user password - Unless the user is very careful with the password choice, the hacker can attempt to discover the password by social engineering or phishing methods.
2. Obtaining the decryption CD - Theft or social engineering can be used to steal or make a copy of the decryption CD.
3. Programmatic collection of decryption key - A Virus/Trojan that can scan memory to find the decryption key can be distributed to the target.
4. Cold boot attack - The scenario is that the decryption keys can be read from memory, but is highly unlikely to happen. The scenario functions with the fact that the RAM memory actually keeps the content for several minutes after power-off, and much longer if cooled. For this attack to succeed, the computer must be stolen while in standby mode or while running, and then within a matter of minutes the memory must be taken out and put into liquid nitrogen.

Frankly, i would be much more careful about the first three items

Conclusions
Encrypting the entire hard drive will make it much more difficult for the thief to extract any valuable information, and can prolong the extraction time to a point when the extracted information will be useless.

Encrypting the entire hard drive will cause performance reduction of the disk subsystem, but this is always acceptable when compared to the protection it offers, even for home users.

Always bear in mind that no amount of encryption will protect you if you don't maintain a secure mindset:

• use strong passwords
• be careful about social engineering approaches
• store recovery disks in protected environment

Related posts

5 rules to Protecting Information on your Laptop

Further reading

• TrueCrypt portal
• Comparison of Disk Encryption Software at Wikipedia

Talk back and comments are most welcome

Following my publication of a the design for Personal Data Protection in a database , I have received emails asking to elaborate on the proper protection of Secure Keys in the infrastructure.



I'll describe it through the following example:
You want to secure some information, therefore you encrypt it. The encrypted data is stored on some computer readable/writable media. For the entire excercise to be useably fast the actual encryption and decryption is done through a computer program, residing on a general purpose computer. This program needs a decryption key in order to recover the data into a useable form.
If you need the encrypted data only for archival purposes, and acces it only very infrequently, you can set up a situation where you have an isolated (non-networked) computer system in a secure room, doing the encryption and decryption and keep the key in a separate vault in a sealed tamper-evident envelope. When the time for decryption comes, an authorized person opens the vault, breaks the seal on the envelope and types in the key in the decryption program.

But in a more realistic situation, the encrypted data will be needed on a daily basis, so it will probably be kept inside a database or a file on the computer. This computer will need to be networked, and some form of server application will be responsible for decrypting and presenting the data to the user. In this scenario, having the decryption key in a vault serves little purpose, since someone will need to type it in at least several times per hour. So, the solution would be to keep the key somewhere inside the computer. Here's the catch: Any secret kept within a computer is actually very very insecure. It is kept in a file on the file system, or in RAM memory. Both locations are accessible at least to all administrators and can easily become subject to a hacker intrusion. Encrypting the key does not improve things since again, there is a decryption key which is available in cleartext. The image below presents a computer system in which the secret key is stored in RAM or HDD. Both are fully accessible by the OS, and can be dumped to be analyzed and the secret key can be retreived.





What is needed is a way to have the key in a safe location, but to be able to obtain it's services for decryption at speeds at which the computer operates. So, we need a tamper evident and secure vault inside the computer. This is the role of the Hardware Security Module (HSM). The HSM is a hardware device which protects its content, and never reveals the content in an unencrypted form to the host computer, and the host computer cannot access and address any of the storage memory of the HSM. If any form of attempt to tamper the HSM is detected, it can be logged or the HSM can self-destruct the secure contents, depending on the security level of the HSM.
The HSM provides services through an API to generate and import secret keys and to encrypt/decrupt data with those keys. The image below presents a computer system in which the secret key is stored in the protected HSM memory. The OS can request a service of decryption of some data, but the secret key is never directly accessible



The HSM modules come in a form of a PCI card or an external device which connects via USB/SCSI/RS232 interface
It's physical tamper resistance is assigned as a level of FIPS-140-2 validation, with levels 1 to 4

• Level 1 - Imposes very few requirements. In general, all components must be "production-grade" and various obvious kinds of insecurity must be absent.
• Level 2 - Imposes Level 1 requirements and adds requirement for physical tamper-evidence and role-based authentication.
• Level 3 - Imposes Level 2 requirements and adds requirement for physical tamper-resistance, identity-based authentication, and a physical or logical separation between the interfaces by which "critical security parameters" enter and leave the module, and its other interfaces.
• Level 4 - Imposes Level 3 requirements byt adds more stringent physical security requirements as well as robustness against environmental attacks.

In the modern world of information security, one should choose a HSM with a minimal level of FIPS-140-2 Level 3. Also, don't just trust the salesman that their HSM is validated at certain level. NIST maintains validation lists for all of its cryptographic standards testing programs (past and present). All of these lists are updated as new modules/implementations receive validation certificates from NIST and CSE.


Related posts
Personal Data Protection - Anonymizing John Doe


Further reading
FIPS 140-2
NIST Validation lists


Talk back and comments are most welcome

I got invited to attend a strategic meeting at a company specializing in medical software (For sake of confidentiality, let's call them Medic ACME).

Medic ACME needed a strategic position on the requirements presented by a customer for very stringent data protection. According to the presented requirements, the customer wants all patients history in a common database, but insists on minimizing the possibility of a leakage of confidential medical histories. The requirements are as follows:

1. Their general staff (non-MD) must track all procedures and all diagnosis for logistical purposes, but should not see the names, SSNs and addresses of patients corresponding to the diagnosis.
2. IT personnel should have no access to patient personal data (names, SSNs and addresses of patients) even if they dump the database.
3. Upon request of an MD, the staff should be able to type in personal data of a patient to retrieve all medical history for the patient
4. Actual personal patient data must be retained and usable for billing and administration purposes, but only to a very limited number of authorized persons

This set of requirements reminded me of the Payment Card Industry - Data Security Standard (PCI-DSS) requirements for protecting Credit Card data.

Medic ACME proposed to use a reversible encryption of all patient personal data. However, this method requires that the encryption key is common knowledge or at least distributed to a very large number of employees. Also, each access will require decryption of data, and an audit log of each access, thus increasing the load on the database and on the application.

My proposition, which is currently under consideration by Medic ACME was as follows:

1. Copy all original personal data from the Medical database into a separate Patients database together with a reference number to maintain the connection between all medical interventions for that patient in the original database. All data in this database will be encrypted with an asymmetric key (public key encrypts, private key decrypts)
2. Create a unique ID string of data from each patient's name, surname and SSN. In the original Medical database, create an SHA1 hash from each ID string, and replace the original personal data with this hash. The Medical database will now contain a nondescript hash and the internal reference number, so there is no personal data in the database to be stolen or read.
3. Contact a public trusted PKI to issue a strong key pair for encryption. Store the public key in the system, and use it to encrypt all data in the Medical database. Store the private key on several smart cards issued to authorized personnel according to requirements.

This method will permit admission of new patients, with immediate encryption and hashing of their personal data. Also, with this method, it is possible to retrieve patients history by entering it's name, surname and SSN

For billing purposes, a special program needs to be written which will require using the private key for decryption of personal data, in order to correlate them with the medical history.

Talk back and comments are most welcome