D-kriptik Blog

So, I recently saw Juno for the first time, and was surprised and happy to hear Kimya Dawson permeate the soundtrack. And, I ate at wd~50, which was, well, an experience - highly recommended if you want to try something truly new.

Anyway, yes, still here. Unfortunately, this rare act of posting will be limited to a quickie - a few miscellaneous items accumulated over a couple of months.

-

A few headaches…

1. Wow, just wow.
   

   The result of this is that for the last two years (from Debian’s “Etch” release until now), anyone doing pretty much any crypto on Debian (and hence Ubuntu) has been using easily guessable keys. This includes SSH keys, SSL keys and OpenVPN keys.

   Update immediately. And be sure to do things such as regenerate all persistent keys that used random data taken from the vulnerable Debian OpenSSL during their generation - some of this type of work is handled automatically when updating your packages (e.g., OpenSSH server keys), but only you know what you have done outside this automated window.

2. I booted up a Windows XP box only to find that some resource of the Logitech QuickCam software had become corrupted, and this resulted in a nasty msi installer loop hitting the box as soon as a user logged in. I found this tool extremely useful in cleaning up the mess.
   

   [..]With the Windows Installer CleanUp Utility, you can remove a program’s Windows Installer configuration information. You may want to remove the Windows Installer configuration information for your program if you experience installation (Setup) problems. For example, you may have to remove a program’s Windows Installer configuration information if you have installation problems when you try to add (or remove) a component of your program that was not included when you first installed your program.

3. Much to my very unpleasant surprise, I upgraded a server over here from Ubuntu Gutsy to Hardy and discovered networking for Xen DomU’s in Ubuntu Hardy 8.04 is somewhat broken. I ended up using the 2.6.24-17-xen kernel from the hardy-proposed repository, but you could also just stick with the Gutsy Xen kernel for DomU’s.
4. When I upgraded to Gnome 2.22 on a particular FreeBSD 7.0 system, certain things, like the clock applet, did not work. This was due to the dbus daemon not being started. Then, the hal daemon and Gnome did not want to play nice together. This page provided the information necessary to get them playing nice - in this particular instance, not mounting procfs was the problem.

Side note, I was helping someone install Ubuntu recently, and it brought to my attention yet again how much I take what I consider to be basic skills for granted when using *nix. Small things, like running an executable from within your environment path versus by directly specifying the path (the most confusing to many example of this seems to be trying to run an executable in the current working directory), are just not common knowledge. Even the whole command line itself is often scary and bizarre to people. This makes it extremely difficult to provide useful guidance for people to blindly follow (posts on this blog should never be assumed to provide step-by-step instructions - they are just some basic notes at best, as extremely helpful comments like this make obvious). And, even Ubuntu is not as trivial to use as it would appear to many that work in the *nix world.

-

Three useful Ubuntu and FreeBSD pages…

USN.

These are the Ubuntu security notices that affect the current supported releases of Ubuntu.[...]

FreeBSD VuXML.

Security issues that affect the FreeBSD operating system or applications in the FreeBSD Ports Collection are documented using the Vulnerabilities and Exposures Markup Language (VuXML).[...]

FreeBSD Security Advisories.

This web page contains a list of released FreeBSD Security Advisories.[...]

-

Story-telling is one of the fundamental tools in a teacher’s toolkit. Having done quite a bit of consulting, I have learned how invaluable a good story is to driving home particular points and building relationships. There is something fundamental about how stories effect us, perhaps stemming from our innate ability to empathesize and our massive pattern recognition horse-power.

Anyway, this site has a useful set of stories. [via exi]

Here are some stories, analogies, research findings and other examples that provide wonderful illustrations for learning, and inspiration for self-development.

In fact, the first story mirrors a recent post.

An old lady had a hearing-aid fitted, discreetly, hidden underneath her hair.

A week later she returned to the doctor for her check-up.

“It’s wonderful - I can hear everything now,” she reported very happily to the doctor.

“And is your family pleased too?” asked the doctor.

“Oh I haven’t told them yet,” said the old lady, “And I’ve changed my will twice already..”

This reminds me of a story I often tell about someone I met a while back, a graduate student in psych. She was studying aspects of the initial meeting/courtship routines of people, and would go out to bars and such and interact with potential suitors. Here these suitors were, following their typical pickup routines and sometimes spilling more than their drinks, and here she was, analyzing their interaction and subsequently writing up notes to be turned into research papers, etc.

-

NIST draft SP 800-108 has been released.

SP 800-108

DRAFT Recommendation for Key Derivation Using Pseudorandom Functions

NIST announces the release of draft Special Publication 800-108, Recommendation for Key Derivation Using Pseudorandom Functions. This Recommendation specifies techniques for key derivation from a secret key using pseudorandom functions (PRF). Please submit comments to draft-SP800-108-comment@nist.gov with “Comments on SP800-108″ in the subject line. The comment period closes on June 28, 2008.

Yet more KDFs.

-

They just don’t quit, do they?

1

This is the first article analyzing the security of SHA-256 against fast collision search which considers the recent attacks by Wang et al. We show the limits of applying techniques known so far to SHA-256. Next we introduce a new type of perturbation vector which circumvents the identified limits. This new technique is then applied to the unmodified SHA-256. Exploiting the combination of Boolean functions and modular addition together with the newly developed technique allows us to derive collision-producing characteristics for step-reduced SHA-256, which was not possible before. Although our results do not threaten the security of SHA-256, we show that the low probability of a single local collision may give rise to a false sense of security.

2

We study the security of step-reduced but otherwise unmodified SHA-256. We show the first collision attacks on SHA-256 reduced to 23 and 24 steps with complexities $2^{18}$ and $2^{50}$, respectively. We give an example colliding message pair for 23-step SHA-256. The best previous, recently obtained result was a collision attack for up to 22 steps. Additionally, we show non-random behaviour of SHA-256 in the form of pseudo-near collisions for up to 31 steps, which is 6 more steps than the recently obtained non-random behaviour in the form of a semi-free start near-collision. Even though this represents a step forwards in terms of cryptanalytic techniques, the results do not threaten the security of applications using SHA-256.

3

[...]First we describe message modification techniques and use them to obtain an algorithm to generate message pairs which collide for the actual SHA-256 reduced to 18 steps. Our second contribution is to present differential paths for 19, 20, 21, 22 and 23 steps of SHA-256. We construct parity check equations in a novel way to find these characteristics. Further, the 19-step differential path presented here is constructed by using only 15 local collisions, as against the previously known 19-step near collision differential path which consists of interleaving of 23 local collisions. Our 19-step differential path can also be seen as a single local collision at the message word level. We use a linearized local collision in this work. These results do not cause any threat to the security of the SHA-256 hash function.

4

[...]We build on the work of Nikoli\’{c} and Biryukov and provide a generalized nonlinear local collision which accepts an arbitrary initial message difference. This local collision succeeds with probability 1. Using this local collision we present attacks against 18-step SHA-256 and 18-step SHA-512 with arbitrary initial difference. Both of these attacks succeed with probability 1. We then present special cases of our local collision and show two different differential paths for attacking 20-step SHA-256 and 20-step SHA-512. One of these paths is the same as presented by Nikoli\’{c} and Biryukov while the other one is a new differential path. Messages following both these differential paths can be found with probability 1. This improves on the previous result where the success probability of 20-step attack was 1/3. Finally, we present two differential paths for 21-step collisions for SHA-256 and SHA-512, one of which is a new path. The success probability of these paths for SHA-256 is roughly $2^{-15}$ and $2^{-17}$ which improves on the 21-step attack having probability $2^{-19}$ reported earlier. We show examples of message pairs following all the presented differential paths for up to 21-step collisions in SHA-256. We also show first real examples of colliding message pairs for up to 20-step reduced SHA-512.

Completely academic, but you know what they say - attacks only get better.

-

Interesting stuff.

NSA/CSS periodically releases declassified documents or indexes to these documents to the public. The documents listed on this page were located in response to numerous requests received by NSA on the various subjects stated and for which there appears to be a general public interest. The date after each entry reflects the most current release date of that material. When additional material for a given subject is updated then a new subject index date is posted. To select a subject index, click on the subject title.

In particular, the Cryptologic Spectrum Articles and Cryptologic Quarterly Articles have some fun reads.

-

An easy to cut ‘n paste into a blog post set of old web server log entries depicting an instance of Tor being used to proxy/anonymize automated probes of this web site.

anonymizer.blutmagie.de - - [13/Mar/2008:00:59:00 -0700] “GET /forum/phpbb/index.php HTTP/1.0″ 404 285 “http://forum.d-kriptik.com/phpbb/index.php” “Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1)”

tor.anonymous.proxy.quex.org - - [13/Mar/2008:00:59:01 -0700] “GET /forum/phpbb2/index.php HTTP/1.0″ 404 286 “http://forum.d-kriptik.com/phpbb2/index.php” “Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1)”

tor.anonymizer.ccc.de - - [13/Mar/2008:00:59:02 -0700] “GET /forum/forums/index.php HTTP/1.0″ 404 286 “http://forum.d-kriptik.com/forums/index.php” “Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1)”

tor.anonymizer.ccc.de - - [13/Mar/2008:00:59:08 -0700] “GET /forum/board/index.php HTTP/1.0″ 404 285 “http://forum.d-kriptik.com/board/index.php” “Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1)”

-

Like heat and humidity, free music and Central Park mean summer. The 2008 schedule is up at the Summer Stage web site. And, the opening Saturday looks good to me.

Vampire Weekend
Kid Sister
Ecstatic Sunshine

Saturday, June 14, 2008
From 4:00 PM to 7:30 PM
Central Park SummerStage

So, enabling Via padlock support on my Ubuntu Gutsy system with the default kernel was kind of, well, trivial. I just configured the relevant kernel modules to be loaded at boot, which involved editing “/etc/modules.conf” and inserting “padlock_aes”, “padlock_sha”, and “via_rng” entries.

With that done, I wanted to use the Via hardware RNG as an entropy source to “/dev/random”, so I installed “rng-tools”.

After that, I wanted to get the widest range of apps using OpenSSL to take advantage of the hardware crypto by default as easily as possible, for which I came back to this page a bunch of times. This patched started me off in one direction, and I ended up heading down the path of the “devcrypto” sort of hack already in the OpenSSL code base.

So, I ended up modifying “crypto/engine/eng_all.c” (and “crypto/engine/engine.h” for the prototype) to add a separate setup function (similar to what was there for “devcrypto”) to load padlock and set it as the default engine (BTW, the “set it as default” step should not be necessary - all it does is get padlock cached as the default engine for the supported algorithms now rather than later), and then I changed the “ssl/ssl_algs.c” “SSL_library_init” function and “crypto/evp/c_all.c” “OPENSSL_add_all_algorithms_noconf” function to call this padlock setup function, which should in theory cover the number of applications out there that call “OPENSSL_add_all_algorithms” and “OPENSSL_add_ssl_algorithms.” Also, I inserted a “ENGINE_cleanup” call into the “crypto/evp/names.c” “EVP_cleanup” function, although I am not sure this is necessary (or wise).

About the only thing annoying in the process was warnings of version information not being found in my OpenSSL shared libraries. I found this useful in fixing the issue.

(Oh, and apologies to my Tor server users, as my server was up and down quite a bit while I played with these things.)

-

A few quickly summarized conversations of possible interest to readers.

I was in a bar talking with a couple of people that were in the USA armed forces and about to go back to deployment in the Middle East. One thing they noted was that the only attack that really scared them when they first deployed over there was IEDs. They said that the fright factor came from the fact that IEDs were something for which they were not trained at the time, IEDs were an unknown. With an outright fire fight, with people firing at them, they knew what to expect; with IEDS, everything could be going as best it can for them over there and then, out of nowhere, boom, they were seriously maimed or dead. Both figuratively and literally, IEDs hit them totally out of the blue. However, with time and experience, IEDs have become a known and expected fact of life over there, something that can be dealt with both strategically and emotionally.

The conversation reminded me of topics like this article (the links I quickly turned up for that article require logins, free or otherwise - an excerpt is here).

Another important dimension of appraisal concerns potential actions: “What can be done about the situation?” Here, controllability and its prerequisite, the stimuli’s predictability, are critical: predictable and controllable adverse stimuli generate less fear, anxiety, and pain than unpredictable and uncontrollable stimuli.

Also, Ekman’s Emotions Revealed came to mind, where there is discussion of fear being influenced by three components - intensity, timing, and coping. Coping seems to be the key being discussed here - e.g., by knowing about the threat, strategies can be developed to reduce the risk posed by the threat, and thus reduce the strength of your fear.

Ok, moving along…

I was speaking with a LEO from the NYPD while waiting for a train. We got onto the topic of PBA cards, where I learned that such PBA cards can be tied to particular officers, which was new to me. The officer informed me that the higher the rank of the officer to which the PBA card is tied, the better the chance you have of getting a reduced charge or just being completely left off the hook when stopped by an officer for some offense. However, someone with me pointed out that this whole situation was not fair, that just knowing someone should not let you off the hook. The officer replied that this was not unfair, you just have to know someone. To this, my acquaintance said that was why it was unfair, because she didn’t known anyone, as was evidenced by her lack of names to drop when getting her second speeding ticket in a roughly two month period recently. The officer’s advice, get to know someone high up in the police force or, better yet, just stop speeding. (Of course, my acquaintance left out that she broke down and cried while getting that latest speeding ticket, and the officer subsequently lowered the speed indicated on the ticket by a number of miles.)

The conversation reminded of another conversation I had a while back with a friend of mine that was an academic. He was complaining that publishing papers in his field was as much about getting the right people to sign up as coauthors (regardless of any actual contribution to the research conducted in the paper) as it was about the research being published. He said the politics degraded the science, which seems similar to my acquaintance above pointing out the politics degrading (the fair application of) the law.

Regardless, the reality is clear - who you know matters. And, as often is the case, these discussions reminded me of Cialdini’s influence, such as the power of reciprocation, social proof, and authority.

-

The latest release of TrueCrypt 5.0 is available, including the use of the XTS mode of operation and whole disk encryption for Windows.

Ability to encrypt a system partition/drive (i.e. a partition/drive where Windows is installed) with pre-boot authentication (anyone who wants to gain access and use the system, read and write files, etc., needs to enter the correct password each time before the system starts). For more information, see the chapter System Encryption in the documentation. (Windows Vista/XP/2003)

XTS mode of operation, which was designed by Phillip Rogaway in 2003 and which was recently approved as the IEEE 1619 standard for cryptographic protection of data on block-oriented storage devices. XTS is faster and more secure than LRW mode (for more information on XTS mode, see the section Modes of Operation in the documentation).

Speed improvements on Windows, an OSX port, and SHA-512 support are also included in this release. Good stuff.

Most everywhere I tested out this release, it worked well, with one exception - an “Insufficient memory for encryption” error I ran into on one of my somewhat older systems. Looking around at a few forums (e.g., here) and at the TC code (e.g., “BootSector.asm”, “BootMain.cpp”, “BootDefs.h”), I don’t see a workaround for the system without modifying the TC code directly to correct/masked the issue. So, this will wait for a bugfix release.

On some systems, when performing the system encryption pretest, the TrueCrypt Boot Loader reports the following error: Insufficient memory for encryption. This issue will be addressed in the next version of TrueCrypt.

Update: To help with debugging the “Insufficient memory for encryption” bug, the TrueCrypt team is requesting your help.

[...]If you encountered this error, you can help us solve this issue by booting a special test ISO image, which displays the amount of free base memory on your system. To do so, please download this file, unpack it, and burn the extracted ISO image to a CD/DVD. Then restart your computer and boot from the CD/DVD. Write down the amount of free base memory displayed by the program and email it to us or include it in a bug report (in either case, make sure the subject is: ‘Base Memory Test Report‘). Thank you.

Update: TrueCrypt 5.0a was released today (2007-02-12). Among the changes…

The memory requirements for the TrueCrypt Boot Loader have been reduced by 18 KB (eighteen kilobytes). As a result of this improvement, the following problem will no longer occur on most of the affected computers: The memory requirements of the TrueCrypt Boot Loader 5.0 prevented users of some computers from encrypting system partitions/drives (when performing the system encryption pretest, the TrueCrypt Boot Loader displayed the following error message: Insufficient memory for encryption).

I should note that one older system of mine mentioned above still fails to meet the memory requirements. Ah well.

Update: TrueCrypt 5.1 has been released.

What is new in TrueCrypt 5.1   (released March 10, 2008)

Included in the changes,

The minimum memory requirements for the TrueCrypt Boot Loader have been reduced from 42 KB to 27 KB (twenty-seven kilobytes). This allows users to encrypt system partitions/drives on computers where the BIOS reserves a large amount of memory. (Windows Vista/XP/2008/2003)

With that reduction, I can now use FDE on that problem machine noted above.

Also of note,

Increased speed of AES encryption/decryption (depending on the hardware platform, by 30-90%). (Windows)

Nice.

Just when you started thinking I was beginning to clean up my messy posting habits, I went and did this…

-

So, I decided to migrate my Tor server, etc. and thought it would be nice to upgrade to Ubuntu Gutsy in the process. (I also took this as an opportunity to setup disk encryption, which was quick and easy.)

As part of the effort, I rebuilt the Xen guest domains I was using on this server. This part turned out to have some quirkiness, as my Xen dom-0 and dom-Us running Ubuntu Gutsy (7.10) would not place nice under the Xen 3.1 that was installed from the latest Ubuntu Gutsy Xen packages (2.6.22-14-xen kernel). By not place nice, I mean the guests would hang during the boot process and/or not provide a usable console.

So, for my reference and yours, I figured it good to point out where I found fixes/workarounds for these issues with Xen 3.1 (2.6.22-14-xen kernel) and Ubuntu Gutsy (7.10) (used for both the host and guests) - this link is where I found some guidance to help fix the issue.

In particular, I found this, which led me to copy “etc/event.d/tty1″ to “etc/event.d/xvc0″ and then replace all occurences of “tty1″ with “xvc0″ within “etc/event.d/xvc0″, useful and it worked across a couple of running dom-U’s. Alternatively, this seems like it might be a workaround, although I did not use it myself.

I found this, which led me to remove offending “hwclock” entries, took care of some hang time.

Also, I did this, which led me to replace “sda” with “xvda” in my guest’s Xen configuration and its “etc/fstab”, just to continue following the general direction Xen is going, although it did not fix any issues.

-

I decided to use djbdns on a dns cache server. As I was setting this up in one of my newly create Xen virtual machines, I found these instructions useful (minus the small part about tinydns, as I wanted a dns cache service - dnscache was my concern, e.g., dnscache); however, I did note one issue on my Ubuntu Gutsy install with regards to the contents of “etc/event.d/svscan” conveyed in those instructions - the use of “runlevel-” was incorrect.

In other words, under Ubuntu Gutsy (7.10), the “etc/event.d/svscan” contents should be something like what follows.

# svscan - daemontools — http://www.froyn.net/blosxom/blosxom.cgi/2007/1/12
#

# This service maintains an svscan process from the point the system is
# started until it is shut down again.

start on runlevel 2
start on runlevel 3
start on runlevel 4
start on runlevel 5

respawn
exec /command/svscanboot

-

I briefly noted this paper on training user’s about phishing.

Our embedded training system works roughly as follows.
People are periodically sent training emails, perhaps from
their system administrator or from a training company.
These training emails look just like phishing emails, urging
people to go to some website and log in. If people fall for
the training email and click on a link in that email, we
provide an intervention that explains that they are at risk for
phishing attacks and gives some tips for protecting
themselves.

Any manager that has ever had to train (or discipline) an employee can probably relate to some of these lessons learned.

· Embed the training into users’ regular activities so they do not have to go to a separate website to learn about phishing attacks.
· Make it clear why users are being warned—for example, what the risks are and what caused the warning.
· Do not delay the warnings; present them immediately after the user clicks on the link.
· Use training messages with the same content that users have just seen, as this helps them concretely relate to what is being discussed in the training message.
· Supplement training text with story-based graphics and annotations.
· Keep the training messages simple and short. One reason the security notices did not work well was too much text.
· Give clear actionable items that participants can easily do to protect themselves.

The “Embed the training into users’ regular activities” reminded me of what I discussed here in quite some length.

Now, lets look at a much better example. In preparation for security training, you have someone sit outside your organization auditing whether people were taking off their ID badges before leaving work, as was mandatory. As part of this audit, the auditor photographs the ID badge of someone leaving the offices still still wearing their ID badge. The next day, that person comes to work to find you sitting at their desk wearing an ID badge with their name but your face. Now, that would make an impact.

However, the actual implementation used in the paper seemed to lack the impact of my example, in that, the people in the study were asked to play someone else, which separated those people from the actions being taken and the consequences of those actions. There was no real world experience here to drive the lessons home.

Oh, and here is our old phishing lesson.

And, what techniques did we employ?

• Wariness - Email should not be trusted by default. Examine email messages closely, especially if they request sensitive information, contain attachments, or provide links, and be sure to establish trust before performing any actions requested by the messages. This is just how I think, and it helps in avoiding scams.
• Research - When in doubt, do some research. (An easy way to do this for messages claiming to be from a company or person you deal with is just call the company or person.) By looking at the raw message, I could see weird characteristics in the headers and the message body that indicated this was a fraud. I then used information taken from the headers and message body to identify proper abuse contacts at the relevant ISPs.

And the easiest one…

• Multiple email accounts with dedicated purposes - By having specialized email accounts that are used only for certain purposes, many scam messages can be quickly identified just by being out of place. (You can also track the dissemination of your email addresses quite well by doing this.) That is how I knew this message was a scam before I even read it its contents.

-

Finally, UAVs have been getting a little attention in my circles for quite a while. So, this article might interest some of you.

Having evolved from military use, drones, or unmanned aerial vehicles (UAVs), are taking to the air in increasing numbers for public-service and civilian roles. They are being operated by groups as diverse as police, surveyors and archaeologists. A UAV helped firemen track the blaze that recently ravaged southern California. [...]

Reminded me of some of the things we did with model airplanes back in the day.

Oh yeah, the linux kernel SHA384 HMAC issue was patched very quickly by Herbert Xu.

I’ve put a similar fix into crypto-2.6.

But, I wanted to note the following, which is why this is in a separate post rather than an update to the original post.

Looking in the code… In sha512.c, the sha384 crypto_alg structure has cra_blocksize set to be SHA384_HMAC_BLOCK_SIZE. cra_blocksize is then used in multiple places by the HMAC implementation in the hmac.c, such as for calculating whether a key needs to be hashed because it is longer than the underlying hash’s blocksize or for the lengths of the outer and inner pads. For example, looking at the function hmac_setkey, the variable bs is set to be the result of a call to crypto_hash_blocksize. If you look at crypto_hash_blocksize, the end result of that function is to return the value of cra_blocksize. As such, the key will be hashed if it is greater than 96 bytes in length, rather than 128. opad and ipad will be treated as 96 bytes in length, rather than 128. Etc. This does not follow the HMAC standard.

Because Herbert Xu’s reply interested me.

Yes, you’re quite right. This does break SHA-384-HMAC. What’s worse is that other implementations also have similar bugs with this. Some even use a block size of 64.

Since this occurs elsewhere, perhaps it is more than just a bug. If so, can someone explain to me why this is being done? This “bug” does not shorten the SHA384 HMAC. (If you want a shorter HMAC, you would use a different HMAC or truncate the HMAC or both.) All I can think is that this “bug” may be used to lower memory usage slightly, but SHA384 is still going to pad to its blocksize. What am I missing?

(Oh, and while we are at it, linux kernel tests for SHA384 HMAC and SHA512 HMAC.

This patch adds tests for SHA384 HMAC and SHA512 HMAC to the tcrypt module. Test data was taken from
RFC4231. This patch is a follow-up to the discovery (bug 7646) that the kernel SHA384 HMAC
implementation was not generating proper SHA384 HMACs.

)

I may be missing something here, but I think that as of today the 2.6.8 and 2.6.18 Debian versions of the Linux kernel as well as the stock 2.6.19 Linux kernel available from kernel.org have a very slightly broken SHA384 HMAC implementation. I do not know if this applies to any other version of the Linux kernel (nor do I care to check).

The fix is just a one line correction to the #defined SHA384_HMAC_BLOCK_SIZE found in crypto/sha512.c. This is incorrectly defined as 96, when it should just be the SHA512_HMAC_BLOCK_SIZE (i.e., 128 bytes). Afterall, SHA384 and SHA512 share everything but the initial values and truncation of the output.

I don’t know if this is new nor do I don’t keep up with whom to notify in the various communities, but, if anyone cares about the one line change, a diff between my corrected version of sha512.c and the current 2.6.18 Debian Linux kernel version (or stock 2.6.19 Linux version) of sha512.c follows.

diff linux-source-2.6.18/crypto/sha512.c /usr/src/linux/crypto/sha512.c

27c27,30
< #define SHA384_HMAC_BLOCK_SIZE 96
---
> // very minor bugfix - 12-04-2006 - Andrew Donofrio
> //#define SHA384_HMAC_BLOCK_SIZE 96
> // SHA384 block size is the same as SHA512 block size
> #define SHA384_HMAC_BLOCK_SIZE SHA512_HMAC_BLOCK_SIZE

Many people said nobody is going to use SHA384 (and, by virtue, SHA384 HMAC). It seems they were right.

Update: Ok, I was bugged by some of you to submit a proper bug report at bugzilla.kernel.org. I did so, and this bug has been assigned bug number 7646.The proposed patch is as follows.

— linux-2.6.19/crypto/sha512.c 2006-11-29 16:57:37.000000000 -0500
+++ linux-2.6.19.ad/crypto/sha512.c 2006-12-06 23:40:25.000000000 -0500
@@ -24,7 +24,7 @@

#define SHA384_DIGEST_SIZE 48
#define SHA512_DIGEST_SIZE 64
-#define SHA384_HMAC_BLOCK_SIZE 96
+#define SHA384_HMAC_BLOCK_SIZE SHA512_HMAC_BLOCK_SIZE
#define SHA512_HMAC_BLOCK_SIZE 128

struct sha512_ctx {

This post was lying around, but I never actually popped it up on the blog. I was just playing around with loop-aes on Debian, since I had used it in days long since gone by and had a desire to try it out again. Loop-aes served its purpose for a short period, but over a month has now passed since I touched any of the Debian boxes around here.

(On FreeBSD 6, I just quickly hacked /etc/rc.d/gbde script to support encryption of the device mounted as /tmp with random keys, much like is already available for swap via /etc/rc.d/encswap, and I played around with using encrypted memory disks, so maybe I will do a quick post on that.)

The way one of my Debian workstations was configured, all of my personal data was stored in the partition mounted as “/home”, and I wanted all data written to this partition transparently encrypted before write (and, of course, transparently decrypted on read). I also wanted this functionality applied to the parition mounted as “/tmp” and the swap partition. While I used GPG to provide services for encryption my email and files, I needed something more robust and settled on loop-aes. I say this as if I researched it, but the reality was that I had used loop-aes a while back, and, in slightly more recent times, brought that knowledge back for a project at my previous employer.

As has been read numerous times in previous Debian posts on this blog, I fired up “aptitude” and searched for “loop-aes”. Lo and behold, there it was. I installed the “loop-aes-source” and “loop-aes-utils” Debian packages. Now, as described in the previous post, the “loop-aes-source” was the code for kernel module, and so it had to be custom built for the custom kernel I was running. Well, as we saw before, that can be quite easy.

From the “/usr/src” directory, I extracted (”tar -xvjf loop.aes.tar.bz2″). This created the directory “modules/loop-aes” under the “/usr/src” directory, which contained the loop-aes kernel module source code.

Unhappily, as I looked at the readme for loop-aes (”cat /usr/src/modules/loop-aes/README | less”), I found that I would have to rebuild the kernel after editing the kernels configuration (/usr/src/linux/.config). While “CONFIG_MODULES=y” and “CONFIG_KMOD=y” were proper, “CONFIG_BLK_DEV_LOOP=m” was not and needed to be changed to “CONFIG_BLK_DEV_LOOP=n”. I made the change, cleaned up a few other areas I wanted to tweak in the kernel, and proceeded to build the new kernel image.

I ran the following from “/usr/src/linux”.

• fakeroot make-kpkg clean
• fakeroot make-kpkg –append-to-version=.03102005 –revision=10.01.Custom –added-modules=loop-aes kernel_image
• modules_image

This built a kernel-image and loop-aes into Debian packages, which could be installed as root by running “dpkg -i kernel-image-2.6.8.03102005_10.01.Custom_i386.deb” and then “dpkg -i loop-aes-2.6.8.03102005_10.01.Custom_i386.deb”.

The kernel was installed as “/boot/vmlinuz-2.6.8.03102005″, a System.map was created as “/boot/System.map.2.6.8.03102005″, and the configuration for the kernel was installed as “/boot/config-2.6.8.03102005″. I ran “depmod -v 2.6.8.03102005″ and, then, to create the initrd-img, I run “mkinitrd -o /boot/initrd-img-2.6.8.03102005 2.6.8.03102005″. In “/boot”, I remove the symbolic links for “config”, “initrd.img”, “System.map”, and “vmlinuz”, and replaced them with symbolic links to the 2.6.03102005 counterparts. Finally, I ran “update-grub”, which updated “/boot/grub/menu.lst” to include this kernel and set it as the default, and then I rebooted the system.

That was the easy part. Now I needed to configure it.

First, I needed to activate the loops for loop-aes. I ran “modprobe -r loop” and then “modprobe loop”. This loaded the loop-aes module and created devices “/dev/loop0″ through “/dev/loop7″ by default. In order to have loop-aes automatically loaded during boot up, which I needed for mounting “/home” automatically during boot, I added the “loop” on a separate line in “/etc/modules”.

The readme for loop-aes contained all sorts of useful examples for setting up the system exactly as I wanted it. After reading the readme (”zcat /usr/share/doc/loop-aes-2.6.8.03102005/README.gz | less”), I decided to create keyfile encrypted with gpg for use by loop-aes for encrypting “/home”. I did this with the following commands as “root”, based on an example in the readme for loop-aes.

• mkdir /etc/loop-aes
• openssl rand -base64 2880 | head -n 65 | tail -n 64 | gpg –symmetric –cipher-algo aes256 -a > /etc/loop-aes/homekey.gpg
• chown root:root /etc/loop-aes/homekey.gpg
• chmod 600 /etc/loop-aes/homekey.gpg

Note: The GPG command above prompted for a password to be entered. This password will be derived into a symmetric key that GPG will use to AES encrypt the keys that will be used to encrypt the “/home” partition. This is one of the weakest links in the chain of this setup, so choosing the longer and more random the password, the better.

After this was completed, I rebooted the system into single user mode. On Debian with the grub bootloader, this was simply a matter of selecting the “Recovery” boot up variant for the kernel desired (2.6.8.03102005 in this case).

My goal was to encrypt swap, “/tmp”, and “/home”. Once in single user mode, I backed up the contents of home (”cd /home; tar -cvjf /root/home.tar.bz2 *”), and then unmounted “/home” (”umount /home”), unmounted “/tmp” (”umount /tmp”), and turned off swap (”swapoff -a”). Next, I edited “/etc/fstab”, placing the configurations for our encrypted partitions at the bottom of the file and commenting our their previous “unencrypted” variants.

/dev/hda5 none swap sw,loop=/dev/loop1,encryption=AES128 0 0
/dev/hda6 /tmp ext2 defaults,loop=/dev/loop2,encryption=AES128,phash=random/1777 0 0
/dev/hda9 /home ext2 defaults,loop=/dev/loop3,encryption=AES128,gpgkey=/etc/loop-aes/homekey.gpg 0 0

Now that the partition for “/home” was going to be encrypted, I needed to reformat it with the following commands.

• losetup -F /dev/loop3
• mkfs -t ext2 /dev/loop3
• losetup -d /dev/loop3

Note: When running this first command, I was prompted to enter the password for the “/etc/loop-aes/homekey.gpg” file. Anytime an attempt to mount “/home” is made, a password prompt appears to enter the password for the “/etc/loop-aes/homekey.gpg” file.

After this was completed, I was turned swap back on (”swapon -a”), mounted “/tmp” (”mount /tmp”), and mounted “/home” (”mount /home”). Next, I extracted my backup of the contents of “/home” into “/home” (”cd /home; tar -xvjf /root/home.tar.bz2 ./”).

Then, I rebooted the system and was good to go.

The negative side effect here was that during boot up, I was prompted to enter the password for the “/etc/loop-aes/homekey.gpg” file as this was required to mount “/home” and mounting of “/home” was configured to happen automatically at boot. I preferred this extra layer during boot, but there are ways to avoid it; however, this avoidance might not be good for the overall security of the configuration.

Note: If this is done on a laptop, beware of suspsend, as it could suspend to disk the plaintext keys for any mounted encrypted partitions. There are steps that can be taken here, such as making sure to manually unmount encrypted partitions and turn off swap before letting a laptop suspend, shutting down a laptop rather than letting it suspend, or having the laptop unmount encrypted partitions and turn off swap automatically as part of the suspend process. The latter can be accomplished using using suspend scripts, but it has the disadvantage of needing a forced unmount that could be problematic to open files contained within the encrypted partition; however, if suspend is configured such that it can occur automatically, then I typically do this as having the plaintext keys written to disk essentially nullifies all of the previous efforts.

—

What reminded me of this lingering blog post was a quick discussion that occured on the Practical Security mailing list. My minor post was bounced, so I will just pop it in down here. (x’s used below so the email addresses are not harvested.)

Date: Tue, 13 Dec 2005 00:07:44 -0500
From: lists <xxxxxxxx@xxxxxxxx.xxx>
To: Alexander Klimov <xxxxxxxx@xxxxxxxx.xxx>
CC: Hagai Bar-El <xxxxxxxx@xxxxxxxx.xxx>, xxxxxxxx@xxxxxxxx.xxx
Subject: Re: [PracticalSecurity] Not-different-enough IVs?

On 12 Dec 2005 12:42:48 +0200, Alexander Klimov wrote:
> On Sun, 11 Dec 2005, Hagai Bar-El wrote:
>> The authors claim that (without encryption) adjacent sectors will
>> have IVs that are just a few bits apart from each other. However,
>> does this matter? Does anyone see the motivation for “hashing”
>> addressed before using them as IVs?
>
> First of all CBC with a non-random IV gives away information about
> plain text: if, say, one (even) sector starts with ‘x…x0′ and the
> next one (odd) starts with ‘x…x1′ (IV is the sector number), then
> the first block of both sectors will be the same.

This made me remember an implementation issue in loop AES (and others),
and a quick Google (loop aes watermark) popped up a post [1] and a paper
[2].

[1] http://www.uwsg.iu.edu/hypermail/linux/kernel/0402.2/1137.html
[2] http://mareichelt.de/pub/notmine/wisa2004.pdf

-Andrew

Before we begin, we recommend this page for some information on how to build the kernel on a GNU/Linux Debian system. We are just describing the steps we went through for this particular system, but that tutorial is more generic and explains some of the options in more detail.

In our previous post, we fixed two problems someone was having with Debian on the Dell Inspiron 8500. With the screen resolution clean in Gnome and surfing the web over our wireless connection, we got started on building a custom kernel.

When we installed the “kernel-sources-2.6.8″ and “ndiswrapper-source” Debian packages on the system previosuly, two files were created in the “/usr/src” directory, “kernel-source-2.6.8.tar.bz2″ and “ndiswrapper-source.tar.bz2″. “kernel-source-2.6.8.tar.bz2″ contained the source code for the GNU/Linux 2.6.8. kernel in a bzip2 compressed tar archive, and that was what we dealt with first.

To extract the source code, we ran “tar -xvjf kernel-source-2.6.8.tar.bz2″ in the “/usr/src” directory. This created a directory “kernel-source-2.6.8″. We removed the old “/usr/src/linux” symbolic link (”rm -rf /usr/src/linux”) and added a new one (”ln -s /usr/src/kernel-source-2.6.8 /usr/src/linux”). By default, virtually everything would be enabled in the kernel configuration and almost all of these enabled features would be loaded as kernel modules (i.e., not compiled directly into the kernel, but rather, compiled into their own object files and loaded as needed by the kernel). If the kernel was built this way, there would be a large number of kernel modules, many of which would never be needed for the system we were running on. For us, we wanted to configure the kernel in order to support the hardware of the laptop and potential additions to the laptop, but not everything under the sun.

To do this, we ran a “dmesg | less” to see what the output from the kernel was during boot up, including the hardware detected. With this information, we could go in and configure the kernel specifically for the system it was running on. The easiest way we found to configure the kernel was to run “make menuconfig” from the “/usr/src/linux” directory. This presented us with a clean menu for walking through the kernels features. From there, we took the output of “dmesg” and determined what could be safely enabled/disabled. For example, we were configuring this kernel for a laptop and the Dell Inspiron 8500 contains a mobile Pentium 4 with speedstep, so we wanted to turn on power management features and cpufreq. Additionally, for this laptop in particular, most of the main hardware functionality was provided by Intel components, the video card was an nVidia, and the onboard NIC was a Broadcom.

Once we had completed configuring the kernel options, it was time to build the kernel. Since this was a Debian system, we did this the Debian way. If not already installed, we needed to install the Debian “kernel-package” package. (Fired up “aptitude”, and searched for and installed “kernel-package”.) Since we were not going to be running as “root” during our build, we needed to use “fakeroot” to build the kernel image package correctly, so, if not already installed, we installed it. (Fired up “aptitude”, and searched for and installed “fakeroot”.)

Now, you may be wondering why we also extracted “ndiswrapper-source” in our previous post. Well, this kernel module was specific to the kernel it was built for but was not part of the main kernel tree, so it would not automatically be built as part of our kernel build. However, Debian made it easy for us to build this as we build our kernel. When we extracted “ndiswrapper-source.tar.bz2″, it was placed in “/usr/src/modules/ndiswrapper”, which was where it needed to be for the command we were about to execute.

Ok, so we had configured the kernel, and we were now ready to build. The following command wes what we executed to create a custom kernel image and “ndiswrapper” Debian packages.

• fakeroot make-kpkg clean
• fakeroot make-kpkg –append-to-version=.11092005 –revision=10.00.Custom –added-modules=ndiswrapper kernel_image kernel_headers kernel_doc modules_image

What did this do?

• “fakeroot make-kpkg clean” cleaned out the kernel source tree from the last build so that no conflicts or other mismatchings came up. For example, we have seens posts about there being a revision conflict detected in the Debian changelog during build when using “–revision” - this could be solved by doing a make clean.
• “fakeroot make-kpkg –append-to-version=.11092005 –revision=10.00.Custom –added-modules=ndiswrapper kernel_image kernel_headers modules_image” built a kernel (”kernel_image”) labeled with the version number 2.6.8.11092005 (”–append-to-version”) and created a Debian package (”make-kpkg”) for it, generated kernel headers (”kernel_headers”) Debian package (”make-kpkg”) for this kernel labeled with the version number 2.6.8.11092005 (”–append-to-version”), and built the ndiswrapper source (”–added-modules”) for the ndis kernel module (”modules_image”) labeled for kernel version 2.6.8.11092005 (”–append-to-version”) and created a Debian package for it (”make-kpkg”). All of the Debian packages included the revision identifier (”–revision”) in their filenames, which was the extent of the use of “–revision”.

These packages were all placed in the “/usr/src” directory ending with “.deb”. To install them (you must be root), we ran “dpkg -i <.deb package name>”, where “<.deb package name>” is the name of the package to be installed, and started with the kernel image. Since the software was packaged with the custom version numbers appended to their names, there was no need to put the packages on hold.

The laptop we were using used “grub” as its bootloader. When the kernel-image was installed from the Debian package, it automatically updated “/boot/grub/menu.lst” using “update-grub”; however, not everything was setup correctly for this to work properly.

Since we installed our custom ndiswrapper kernel module, we wanted to be sure all of our kernel module dependencies are configured. In order to do so, we ran “depmod -v 2.6.8.11092005″.

Our kernel was installed as “/boot/vmlinuz-2.6.8.12092005″, a System.map was created as “/boot/System.map.2.6.8.11092005″, and the configuration for the kernel was installed as “/boot/config-2.6.8.11092005″. There was no “initrd-img” created for this kernel. To create the “initrd-img”, we ran “mkinitrd -o /boot/initrd-img-2.6.8.11092005 2.6.8.11092005″.

Next, we ran “update-grub” and rebooted, selecting our new kernel 2.6.8.11092005. All went well, but if it had not, we would have booted into an older kernel, uninstalled the packages, reconfigured our custom kernel, rebuilt the packages, reinstalled the packages, and rebooted.

We are good to go.

We were recently enlisted to help with the post-installation issues of a Debian distribution (v3.1 Sarge - 2.4.7 kernel) of GNU/Linux on a Dell Inspiron 8500. The install went cleanly enough for the person, and everything was generally working. We were asked to fix two things, the screen resolution (15.4 UXGA) in X Windows (Gnome desktop) and to get the wireless card (Dell TrueMobile 1300) working (with WPA). Also, the person wanted a simple firewall setup.

So, in we dived. First things first, lets do an update/upgrade. We checked “/etc/apt/sources.list” just to be sure the “deb http:security.debian.org/ stable/updates main contrib” was in there, and then we ran “apt-get update” followed by “apt-get upgrade” to update the list of versions for the installed packages and then to perform the upgrade of those packages that had new versions available.

Once that was completed, we added “deb http://http.us.debian.org/debian stable main contrib” to “/etc/apt/sources.list” to increase the list of available packages to include all of those at debian.org rather than just those provided on the installation media used. Now, using “aptitude”, we see a huge set of software available for installation. Debian packages are an amazing way to install and uninstall software on a Debian system, and the application “aptitude” provides a clean interface for doing so.

Anyway, after confirming with the person there was no reason to be running the 2.4.7 kernel, we fired up “aptitude”, searched for and installed the “kernel-image-2.6.8-2-686″ Debian package, and rebooted the system with that kernel. We also installed the “kernel-source-2.6.8″ Debian package for use in the near future. This later kernel makes life easier for things like sound and network drivers.

1. Screen resolution

   So, problem 1 was the screen resolution on the LCD. The video driver installed out of the box worked fine, but the XF86Config had bizarre settings. So, we had to update the “Monitor” and “Screen” sections of the “/etc/X11/XF86Config-4″ to have proper settings for the widescreen liquid crystal display (LCD) provided by the laptop, and we found a good sample “XF86Config-4″ for this laptop here.

   With that taken care of, we moved on to problem 2, the wireless card.

2. Wireless Card

   Once again, using “aptitude”, we searched for and installed the “wireless-tools” Debian package. The person was using a wireless access point (AP) with the SSID of “D_dash_KRIPTIK_dot_COM” configured for WPA-PSK and providing DHCP. The wireless card was esentially built into the machine and was not going to be removed or changed, so we went in and edited “/etc/network/interfaces” to include an entry along the lines of:

   auto wlan0
   iface wlan0 init dhcp
   wireless_essid D_dash_KRIPTIK_dot_COM
   wireless_mode Managed

   You could also configure a (blech) WEP key here, but this was not necessary for our purposes. These settings might get overriden by future configuration, especially that involved for WPA, and could also be modified on the fly using “iwconfig”.

   Dell had recently issued a new driver for the TrueMobile 1300 mini-PCI wireless card, which can be found here, and we downloaded this on a machine running Windows XP. We ran this file on the Windows machine, and it automatically extracted a set of files and then ran the install program for the driver. The installation cancelled the installation as all we needed were the extracted files. By default, these files were placed in “C:\Dell\Drivers\R102320″ directory. We copied the files “bcmwl5.inf” and “bcmwl5.sys” to a USB drive for easy transport to the laptop, but this could have just as easily been a floppy disk, CD, and transferred via the network (on the Ethernet port provided by the laptop). We plugged the USB drive into the laptop and this was mounted as “/media/usbdisk”.

   Now, obviously, the drivers we just downloaded from Dell are for Windows and there are drivers released for GNU/Linux. However, with a nifty piece of software called “ndiswrapper“, we can use these Windows network drivers on our GNU/Linux machine. But, first, we need to install “ndiswrapper”. We fire up “aptitude”, search for “ndiswrapper”, and we find the necessary Debian packages for installing “ndiswrapper”. We install the “ndiswrapper-modules-2.6.8-2-686″, “ndiswrapper-utils”, and “ndiswrapper-source” Debian packages.

   After installing “ndiswrapper”, we needed to configure it. First, we installed the wireless card’s driver onto the system from the USB drive by running “ndiswrapper -i /media/usbdisk/bcmwl5.inf”. Next, we needed to find the device ID for the wireless card. We did this by running first “lspci”, which indicated that “0000:02:03.0″ was our wireless card, and then we ran “lscpi -n”, which gave the device ID of “14e4:4320″ for “0000:02:03.0″. “14e4:4320″ was what we needed to know. With this information, we ran “ndiswrapper -d 14e4:4320 bcmwl5″ to properly install the driver for the wireless card. We then ran “ndisdriver -m” and “ndisdriver -hotplug” to make tie any remaining loose ends.

   If you do not have WPA turned on for your AP or other wireless device, you could have a wireless card with a working connection at this point. However, for our setup, the wireless card was still useless. We needed one additional piece of software to provide our support for WPA, “wpasupplicant“, which is useful for cases such as these where the wireless card does not normally change or get removed. The usual routine - “aptitude”, search for “wpasupplicant”, and install “wpasupplicant”.

   We created a directory “/var/run/wpasupplicant” by running “mkdir /var/run/wpasupplicant”. We took the example “wpa_supplicant.conf” file provided with wpasupplicant and edited it to suit our needs. Essentially, we left the defaults in the example alone until “# network block” section. There, we removed all of the example entries and put in the following.

   network={

          ssid="D_dash_KRIPTIK_dot_COM"
          proto=WPA
          key_mgmt=WPA-PSK
          pairwise=CCMP
          group=CCMP
          psk="*****************************************"
          priority=1
   

   }

   Of course, the “*****************************************” should be replaced with the actual pre-shared key as configured on the AP. We placed our “wpa_supplicant.conf” in “/etc”.

   There was now a script in “/etc/init.d” that could be invoked during the various runlevels to startup the “wpasupplicant” software during boot. Before we configured this, we needed to modify “/etc/default/wpasupplicant” to properly reflect our configuration. We needed to edit “/etc/default/wpasupplicant” to include the proper options for when “/etc/init.d/wpasupplicant” was invoked. So, we opened “/etc/default/wpasupplicant”, and changed “ENABLE” to equal “1″ and “OPTIONS” to equal “-Bw -c /etc/wpa_supplicant.conf -Dndiswrapper -iwlan0″. Next, we created a symbolic link in “/etc/rcS.d” before the standard networking scripts were invoked by running “ln -s ../init.d/wpasupplicant S38wpasupplicant” from the “/etc/rcS.d” directory.

   We rebooted, and watched as “wpasupplicant” was invoked, “wlan0″ was brought up, and then “wlan0″ was assigned an IP via DHCP. Beautiful, www.google.com loaded perfectly in Firefox.

3. Simple Firewall Configuration

   Well, we were connected to the AP, so what about that firewall? “netfilter” was built into our kernel, and “iptables” was installed on the system, which provides a way to configure “netfilter”. However, we needed a simple interface for configuring “netfilter” through “iptables”, so we decided to install “lokkit”. We ran “aptitide”, searched for “lokkit”, and installed both the “lokkit” and “gnome-lokkit” packages. We then ran “gnome-lokkit”, walked through the configuration options with the person, and we were all set.

Whew.

Remember when we grabbed the “kernel-source-2.6.8″ package a minute ago? Our next post will discuss what we did we that.