D-kriptik Blog

I am posting these snippets in a period of quiet between bedraggling, booming storms. Alas, dear reader, another set of quickies, as summertime rolls.

-

So, the DNS implementation flaw has (allegedly) been revealed. Grinding through weak state combined with additional RR trickery gets the job done. Good stuff. Adding more entropy to the state information is one way to fend off feasibility, as demonstrated by djbdns (yes, I mentioned djbdns at one point). Patches abound.

Update: An exploit.
-

The 0.2.0.x branch of Tor has gone from alpha to release, with 0.2.0.30 being the first version deemed fit for primetime.

I tagged Tor 0.2.0.30, the stable release of the 0.2.0.x series, on Tuesday.

You can read all about it here:
https://svn.torproject.org/svn/tor/tags/tor-0_2_0_30/ReleaseNotes

We haven’t made an official announcement yet, because we’re waiting for Torbutton 1.2.0 to go stable so we can build packages for the Windows and OS X folks.

From the release notes…

Changes in version 0.2.0.30 - 2008-07-15
This new stable release switches to a more efficient directory distribution design, adds features to make connections to the Tor network harder to block, allows Tor to act as a DNS proxy, adds separate rate limiting for relayed traffic to make it easier for clients to become relays, fix a variety of potential anonymity problems, and includes the usual huge pile of other features and bug fixes.

Great work.

-

The TrueCrypt team has been quite busy it seems, with two major releases this year within a few months of each other. So, TrueCrypt 6 has been rolled out, and I took note of the following new features.

Parallelized encryption/decryption on multi-core processors (or multi-processor systems). Increase in encryption/decryption speed is directly proportional to the number of cores and/or processors.

Each volume created by this or later versions of TrueCrypt will contain an embedded backup header (located at the end of the volume). Note that it is impossible to mount a volume when its header is damaged (the header contains an encrypted master key). Therefore, embedded backup headers significantly reduce this risk. Also note that a backup header is not a copy of the original volume header because it is encrypted with a different header key derived using a different salt. For more information, see the subsection Tools > Restore Volume Header.

More great work.

-

Remember cold boot? Well, the software created as part of the research has now been released.

July 16, 2008 — This page contains source code for some of the software that we developed in the course of this research. These prototype applications are intended to illustrate the techniques described in the paper; we are unable to provide technical support.

-

You may have noticed this.

4Q08 The second draft of FIPS 140-3 will be published for public comment (subject to change).

-

A few new modes of operation for the AES have popped up at NIST in somewhat recent months. One of these, XTS, is now being proposed by NIST for approval for government use, meaning it could become an approved mode of operation for AES under FIPS 140.

The P1619 Task Group of the Security in Storage Working Group (SISWG) of the Institute of Electrical and Electronics Engineers, Inc. (IEEE) has submitted the XTS-AES algorithm (XTS, for short) to NIST as an encryption mode of operation of the Advanced Encryption Standard (AES) block cipher. Although XTS does not provide authentication in order to avoid expansion of the data, it is designed to provide some protection against malicious manipulation of the encrypted data. Subject to the 90-day period of public comment that is described below, NIST proposes to approve XTS for government use under the auspices of FIPS Pub. 140-2.

-

Draft SP 800-107, Recommendation for Applications Using Approved Hash Algorithms, has been published and is open to public comment until 09-Oct-2008.

This Recommendation provides security guidelines for achieving the required or desired security strengths of several cryptographic applications that employ the approved cryptographic hash functions specified in Federal Information Processing Standard (FIPS) 180-3 [FIPS 180-3], such as digital signature applications [FIPS 186-3], Keyedhash Message Authentication Codes (HMACs) [FIPS 198-1] and Hash-based Key Derivation Functions (HKDFs) [SP 800 56A] & [SP 800 56B].

Update: Related to the SP 800-107 news, a revision to FIPS 198 has been released, FIPS 198-1.

APPENDIX A: The Differences Between FIPS 198 and FIPS 198-1
The length of truncated HMAC outputs and their security implications in FIPS 198 is not mentioned in this Standard; instead, it is described in SP 800-107. The discussion about the limitations of MAC algorithms has been moved to SP 800-107. The examples and OIDs have been posted on the NIST web sites referenced in Section 6.

-

Yes please.

Abstract. Password-Authenticated Key Exchange (PAKE) studies how to establish secure communication between two remote parties solely based on their shared password, without requiring a Public Key Infrastructure (PKI). Despite extensive research in the past decade, this problem remains unsolved. Patent has been one of the biggest brakes in deploying PAKE solutions in practice. Besides, even for the patented schemes like EKE and SPEKE, their security is only heuristic; researchers have reported some subtle but worrying security issues.

In this paper, we propose to tackle this problem using an approach different from all past solutions. Our protocol, Password Authenticated Key Exchange by Juggling (J-PAKE), achieves mutual authentication in two steps: first, two parties send ephemeral public keys to each other; second, they encrypt the shared password by juggling the public keys in a verifiable way. The first use of such a juggling technique was seen in solving the Dining Cryptographers problem in 2006. Here, we apply it to solve the PAKE problem, and show that the protocol is zero-knowledge as it reveals nothing except one-bit information: whether the supplied passwords at two sides are the same. With clear advantages in security, our scheme has comparable efficiency to the EKE and SPEKE protocols.

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

I found this post interesting having just had yet another discussion about entropy in this seed, key, password, etc. world of mine.

The term “Mind Projection Fallacy” was coined by the late great Bayesian Master, E. T. Jaynes, as part of his long and hard-fought battle against the accursèd frequentists. Jaynes was of the opinion that probabilities were in the mind, not in the environment - that probabilities express ignorance, states of partial information; and if I am ignorant of a phenomenon, that is a fact about my state of mind, not a fact about the phenomenon.

Of course, this speaks to entropy. In our seed, key, password, etc. world, entropy is a measure of uncertainty. It is what someone does not know. As such, entropy is subjective. If I know a password, it has no entropy; however, to someone that knows close to absolutely nothing about a password, it has close to maximum entropy.

So, when we talk about the entropy of things like passwords, what we generally mean is the amount of uncertainty, or the lack of information, about that password given some set of assumptions of the information available about that password. And, since entropy is subjective, any measurement of this uncertainty that we produce will likely just be a bound (e.g., an estimate of the maximum possible value) based on particular assumptions.

Ok, lets look at a very simple example with passwords (I banged this out quickly, so hopefully I didn’t make any obvious mistakes)…

Consider the set of passwords exactly 8 digits in length and composed of case-insensitive, repeatable, alphanumeric characters. Given that, each digit of the password can be 1 of 36 characters (i.e., 0-9 or a-z), and, given the passwords are 8 digits in length, there are 36*36*36*36*36*36*36*36 = 36⁸ possible passwords.

Flipping through “The Mathematical Theory of Communication”, Shannon defined entropy, or the measure of uncertainty, for a set of probabilities p₁,…,p_n, as H = -∑ p_i log p_i, where p_i is the probably of an event i.

Looking at SP800-90, min-entropy, another measure of uncertainty, for a set of probabilities p₁,…,p_n is defined as H = -log₂(p_max), where p_max is the maximum p in p₁,…,p_n.

Now, lets say you choose a password from this set using a selection method that ensures that the probability of any character being chosen for a digit of the password is 1/36 (i.e., each digit of the password is equally likely to contain any of the 36 possible characters). Once you have chosen and know your password, what is the entropy of that password to you? Well, 0, as you know the password.

In other words, each digit of the password is known to you, meaning the probably of one particular character being in each digit of the password is 1, while the probably of any other characters being in that same digit is 0. So, there is only one p_i for each digit of the password, and our Shannon H = -∑ p_i log p_i = -1 log 1 = 0 and our min-entropy H = -log₂1 = 0. So, for each digit of our password, H=0. And, treating the digits of our password as independent, the entropy of our password is sum of the individual entropy we calculated for each digit, namely 0+0+0+0+0+0+0+0=0.

Another way of looking at this is that the chance that you will guess your password given you know your password is 1/1=1. Translating that to percent, 1*100 = 100%.

Now, lets say an outside observer comes along who knows nothing about the password you selected above except that it is in this set of possible passwords we have defined. For this attacker, the entropy of the password is quite different, as there is quite a bit uncertainty about your password.

As stated, each digit of the password can be 1 of 36 characters, and this outsider has no information that would bias them towards any particular character being in any particular digit of the password. So, the probably of a particular digit in the password being a particular character is 1/n, where n is the number of potential characters, or 1/36.

Plugging that into H, we get Shannon H = -∑ p_i log p_i = -((1/36)*log(1/36) + (1/36)*log(1/36) + …_{repeat 32 more times}… + (1/36)*log(1/36) + (1/36)*log(1/36)) = log(36) ≈ 1.5563 (5.1699 bits) or our min-entropy H = -log₂(1/36) ≈ 5.1699. So, for each digit of our password, H ≈ 1.5563 (5.1699 bits). And, since this observer knows nothing to imply any dependence between the digits of the password, the digits can be treated as independent and so the total entropy for the password will equal the sum of the entropy of each digit, or roughly 1.5563+1.5563+1.5563+1.5563+1.5563+1.5563+1.5563+1.5563=1.5563*8=≈12.4504 (5.1699+5.1699+5.1699+5.1699+5.1699+5.1699+5.1699+5.1699=5.1699*8=≈41.3594 bits)

Another way of looking at this is that the chance this outside observer will guess our password is 1/(36⁸)=1/2821109907456≈.00000000000035447. Translating that to percent, .00000000000035447*100 = .000000000035447%.

This situation is actually the maximum measure of uncertainty for a password taken from our set of passwords, as it assumes that every character from our character set to be equally likely in every digit of the password and that each digit is independent of the others. (When people ask if their passwords are strong, generally they are asking whether they are near this maximum bound.)

Of course, there is a large range in between the two entropy extremes in this example, and where someone’s uncertainty about a password falls in that range depends on what they know about the password. For example, if they know the password is an English word but not what word exactly, the entropy slides over towards the minimum end. If they know your password is the name of someone very close to you but not what name exactly, then the entropy likely drops to close to zero.

Since I mentioned it above, Appendix A of of SP800-90 (Recommendation for Random Number Generation Using Deterministic Random Bit Generators) discusses the subjectiveness of entropy.

The word “entropy” is used to describe a measure of randomness, i.e., a description of how hard a value is to guess. Entropy is a measure of uncertainty or unpredictability and is dependent on the probabilities associated with the possible results for a given “event” (e.g., a throw of a die or flip of a coin).

Entropy is relative to an adversary and his ability to observe or predict a value. If the adversary has no uncertainty about the value, then the entropy is zero (and so is the security of the consuming application that relies on the DRBG). Any assessment of the entropy of a particular value is actually an assessment of how much of the value is unknown to the adversary.

That document also discusses calculating entropy, recommending min-entropy over Shannon entropy. In the example calculations here, both result in the same entropy estimate, but, in general, min-entropy will produce a more conservative (i.e., less than or equal to) estimate of entropy than Shannon entropy.

***

A new version of mixmaster has been released. [via remops and others]

Mixmaster 3.0 has been released this week. This is the first major version release since 2.9, and a continuation of that code, though it incorporates numerous improvements, feature enhancements, and bug-fixes. It is recommended that you upgrade your remailers to this version.

The next major version of Tor is in the release candidate phase too.

-

For the wannabe gargoyles amongst us… [via tt]

Researchers at the University of Tokyo have developed a smart video goggle system that records everything the wearer looks at, recognizes and assigns names to objects that appear in the video, and creates an easily searchable database of the recorded footage. Designed to function as a high-tech memory aid, these “Cyber Goggles” promise to make the act of losing your keys a thing of the past, according to head researcher professor Tatsuya Harada.

And, yes, I would wear those.

-

Finally, if you build it, they will come.

Abstract—Our study analyzes the security and privacy properties of an implantable cardioverter defibrillator (ICD). Introduced to the U.S. market in 2003, this model of ICD includes pacemaker technology and is designed to communicate wirelessly with a nearby external programmer in the 175 kHz frequency range. After partially reverse-engineering the ICD’s communications protocol with an oscilloscope and a software radio, we implemented several software radio-based attacks that could compromise patient safety and patient privacy. Motivated by our desire to improve patient safety, and mindful of conventional trade-offs between security and power consumption for resource constrained devices, we introduce three new zero-power defenses based on RF power harvesting. Two of these defenses are humancentric, bringing patients into the loop with respect to the security and privacy of their implantable medical devices (IMDs). Our contributions provide a scientific baseline for understanding the potential security and privacy risks of current and future IMDs, and introduce human-perceptible and zero-power mitigation techniques that address those risks. To the best of our knowledge, this paper is the first in our community to use general-purpose software radios to analyze and attack previously unknown radio communications protocols.

As some of you may have noticed, I am big of using “local grass roots networks for intelligence gathering” (e.g., “walking the beat”), meaning something like enlisting everyday people to get out there and gather intelligence during their normal everyday activities. From barstaff/waitstaff to the beautiful to those that pick up the trash to techies to those that just hang out a lot, you can pull together a wealth of information on particular subjects of interest to you, from specific material (e.g., make a note if you hear of a great apartment becoming available) to just general feelings (e.g., make a note about anything that strikes you as odd or foolish or interesting or official). So, here is a more off the wall example…

Now, “we all know” having sensitive conversations walking down the street in NYC is not necessarily the wisest thing to do; however, people tend to think it is acceptable when no one appears to be within direct earshot. But, in many places within NYC, apartment intercoms are within earshot. And, many intercoms give no indication of when “listen” is activated.

Sure, there are lots of ways to eavesdrop on public conversations, but intercoms are a quick and easy way for just about anyone living in an apartment in NYC to do a bit of local surveillance using a standard apartment feature available to them at this very moment. And, if you live in the financial district or some area full of well to do business or political people or what have you, there could be lots of potential to gather both dirt and confidential information via intercoms.

Anyway, it might be interesting to pull together a weekly or monthly or what have you podcast composed of, well, interesting conversations (or even video in some cases) captured via intercoms just to see the results. (Of course, before doing so, it would be good to find out if recording public conversations is legal in whatever jurisdiction the recording is taking place?)

On a side note, while “we all know” discussing or reading sensitive information does not mix with public places, it is still quite common for people to have sensitive conversations in public directly within earshot of others and read sensitive documents in public directly within eyeshot of others - for example, someone was reading a hard copy of a design spec for a financial management system, including the security section, on the train a couple of days ago in plain view (this particular instance stood out to me because the system was for a company I own stock in). In NYC, commuters seem to be particularly prone to exhibiting these behaviors, which gives rise to some potential recon options, like enlisting people that, say, ride the subway during rush hour to keep an ear/eye out for interesting information. That nifty cell phone might be of use here too.

Yes, still “keepin’ it old school” in 2008.

While this post was somewhat in good fun, it did bring to mind a conversation I had with a bartender back in DC a number of years ago about Romania. He told me that many talented techies there turn to computer crime and such because there are so few opportunities for them to use their skills in other ways. You know, as the economy slips in the USA, this type of situation may hit hard close to home - which could mean, say, HUMINT will be even cheaper and more plentiful (e.g., chat up a laid off employee), and so on.

So, straight off the hotplug post, now there is a paper discussing the recovery of encryption keys from RAM after a machine has been powered off. [hat tip to a friend and Metzger's list]

Contrary to popular assumption, DRAMs used in most modern computers retain their contents for seconds to minutes after power is lost, even at room temperature and even if removed from a motherboard. Although DRAMs become less reliable when they are not refreshed, they are not immediately erased, and their contents persist sufficiently for malicious (or forensic) acquisition of usable full-system memory images. We show that this phenomenon limits the ability of an operating system to protect cryptographic key material from an attacker with physical access. We use cold reboots to mount successful attacks on popular disk encryption systems using no special devices or materials. We experimentally characterize the extent and predictability of memory remanence and report that remanence times can be increased dramatically with simple techniques. We offer new algorithms for finding cryptographic keys in memory images and for correcting errors caused by bit decay. Though we discuss several strategies for partially mitigating these risks, we know of no simple remedy that would eliminate them.

In my previous post, I said “However, if you pulled the plug, then the plaintext key would be lost.” without qualifiers - I generally thought a 10 second rule was appropriate, that is, remove power and 10 seconds later the key would be too difficult for most attackers to recover. Well, it looks like a 60 second rule is a better baseline and perhaps a 515 minute rule is the fairly conservative way to go.

Our first tests measured the decay rate of each memory module under normal operating temperature, which ranged from 25C to 44C depending on the machine (see Figures 1, 2, and 3). We found that the dimensions of the decay curves varied considerably between machines, with the fastest exhibiting complete data loss in approximately 2.5 seconds and the slowest taking an average of 35 seconds. However, the decay curves all display a similar shape, with an initial period of slow decay, followed by an intermediate period of rapid decay, and then a final period of slow decay.

And,

Imaging residual memory contents requires no special equipment. When the system boots, the memory controller begins refreshing the DRAM, reading and rewriting each bit value. At this point, the values are fixed, decay halts, and programs running on the system can read whatever data is present using normal memory-access instructions.

In other words, if someone quickly powers the system back up after the plug is pulled, the decay is stopped. So, turn the system back on within a few seconds, and it is likely quite easy for anybody to quickly reboot the machine from, say, a USB token that has just enough software to dump the memory and then pull the key from that dump. Throw in some error correcting algorithms based on, say, the key schedules used in AES, and key recovery in the presence of some memory degradation improves drastically.

Our experiments (see Section 3) show that it is possible to recover memory contents with few bit errors even after cutting power to the system for a brief time, but the presence of even a small amount of error complicates the process of extracting correct cryptographic keys. In this section we present algorithms for correcting errors in symmetric and private keys. These algorithms can correct most errors quickly and uniquely even in the presence of relatively high bit error probabilities in the range of 5% to 50%, depending on the type of key.

And, yes, they demonstrated all of this on TrueCrypt,

We tested TrueCrypt versions 4.3a and 5.0a running on a Linux system. We mounted a volume encrypted with a 256-bit AES key, then briefly cut power to the system and used our memory imaging tools to record an image of the retained memory data. In both cases, our keyfind program was able to identify the 256-bit AES encryption key, which did not contain any bit errors. For TrueCrypt 5.0a, keyfind was also able to recover the 256-bit AES XTS tweak key without errors.

As well as, on dm-crypt (for those, say, using FDE setup during the installation of Ubuntu Gutsy).

We tested a dm-crypt volume created and mounted using the LUKS (Linux Unified Key Setup) branch of the cryptsetup utility and kernel version 2.6.20. The volume used the default AES-CBC format. We briefly powered down the system and captured a memory image with our PXE kernel. Our keyfind program identified the correct 128-bit AES key, which did not contain any bit errors. After recovering this key, an attacker could decrypt and mount the dm-crypt volume by modifying the cryptsetup program to allow the raw key to be input.

What to do?

Memory imaging attacks are difficult to defend against because cryptographic keys that are in active use need to be stored somewhere. Our suggested countermeasures focus on discarding or obscuring encryption keys before an adversary might gain physical access, preventing memory-dumping software from being executed on the machine, physically protecting DRAM chips, and possibly making the contents of memory decay more readily.

So, shutdown and remove power from that machine when not in use. And, make sure no one accesses that machine for 515 minutes (or more) after removing power. You may even want to create a bootable CD-ROM or USB token that specifically scrubs all system RAM, and boot from that after finishing up using encryption tools.

Good stuff.

Update: Here is the site covering the paper’s release, which includes a FAQ.

Update: Declan McCullagh has a slide show demonstrating the attack conducted against his laptop, as well as, an article on the topic.

Update: Just a quick note, since this post has given me some grief in my circles - you know, if the value of the data you are protecting is such that an attacker would be willing to, say, employ electron microscopes and such in the process of analyzing your DRAM, then you really need to start looking into very specific hardware setups (e.g., hardware cryptographic modules, physical destruction mechanisms, etc.) to meet your needs, because that generic Dell machine running that generic flavor of Windows with whatever cryptographic software on top is very likely not going to cut it for your purposes.

Update: Look at that.

When the idea of memory retaining state for a short time was first brought to my attention a little over a year ago, I ran a few experiments similar to this one, just to prove it to myself. The desktop machines I tried would hold state for anywhere between 5 and 10 seconds without power, whereas my laptop, with no battery or wall power, would maintain state for an amazing 10 minutes.[...]

The Princeton researchers applied this method to the recovery of encryption keys, with great results. They also cooked up a way to image the contents of RAM with a very small footprint, only overwriting a small amount of memory in the process. Unfortunately, at the time of writing this, their tool, ram2usb, hasn’t been released. I decided that it wouldn’t be hard to go ahead and implement one myself, based off their paper and youtube video posted above, so that I (and others) can go ahead and start having fun.

So, as a small side project, I’ve written “msramdmp”, the McGrew Security RAM Dumper. Enjoy!

Update: Yes, yes, if the wire is available, why boot cold when you could just use fire.

Update: The software created by the original researchers has now been released http://citp.princeton.edu/memory/code/.

July 16, 2008 — This page contains source code for some of the software that we developed in the course of this research. These prototype applications are intended to illustrate the techniques described in the paper http://citp.princeton.edu/memory/; we are unable to provide technical support.

I feel like I am beating a dead horse with the start of this post. I tried to go a little off course from there.

-

Another discussion of FIPS 140 has been kicked off on SAAG. Besides the kick off message (on including FIPS-approved algorithms in a possible IETF recommended set of crypto algorithms), this post (on product customer demand for FIPS 140) and this post (on the general pain of the process) are probably of most interest, but the entire thread may be worth a read if FIPS 140 matters to you. (Oh, and this made me laugh.)

This post of mine from a year ago seems relevant to some of what is being said.

1. A vendor has been put at a competitive disadvantage because they do not have FIPS 140 validation. Perhaps their competitors have it. Perhaps a bid requires it. Whatever the case may be, they don’t have it, so now they want to tear it down.

   Also found here are people that just dislike FIPS 140 or, perhaps, standards in general.

2. A vendor has gone through the process, and it was quite painful. So, now they vent about all the changes they had to make, how silly particular requirements were, how incompetent the lab staff was, etc.
3. An expert tells stories of how the requirements are ambiguous and the labs all vary in how they interpret the requirements.

   Also found here (and often quite different from the previously described expert) are people that have run into FIPS a number of times over the years, which has caused them exposure to differing requirements without having seen the evolution of those changes.

In that lengthy post, I discuss some points often causing pain.

1. Vendor misunderstanding of the FIPS 140 requirements and terminology.
   [...]
2. Vendor misinterpretation of lab (or NIST/CSE) questions and issues.
   [...]
3. Labs can, and do, make requests and recommendations.
   [...]
4. New labs, new lab staff, new technologies, and new revisions of FIPS 140 (and related) standards can make for created requirements. (This is where you can find the most variation among labs.)
   [...]

Anyway, I think a couple of additional points might be relevant to some of what I read in the latest SAAG thread.

First, I don’t think the concept of failure in a FIPS validation effort is quite so rigid as is being implied in parts of the SAAG discussion. During a FIPS validation effort, the lab (during testing) or NIST/CSE (during review) may bring up issues that a vendor has to address. These issues are often areas in which the module may be failing to meet particular FIPS requirements. This does not mean the module “fails,” it just means that the issues raised must be addressed before the module “passes.” In general, issues often boil down to some of the following:

1. Clarification - the issue raised is just seeking some short clarification about the product’s workings and/or how a requirement is met. A quick written or verbal response (e.g., answering a question) can often be enough.
2. Documentation - the issue raised is about incorrect, confusing, or incomplete documentation. Modifying the documentation is normally the fix here. (Even though what follows in 3 is often what vendors dread most, 2 can also lead to much pain if the lab starts questioning technical aspects of the product and heads down all sorts of testing paths that would otherwise have been avoided (i.e., prepare documentation that gives the lab what it needs in an easy to use form).)
3. Technical - the issue raised is actually a technical problem with the product in regards to meeting the requirements. Here is where the product itself may have to be modified, and this is what most vendors want to avoid once they are knee deep in the validation (i.e., get the product meeting the requirements before the lab testing gets underway).

In all three cases, the “failure” can be corrected and the product can continue on with its validation. Depending on the issues raised, labs will often continue working on the validation effort in other areas while the vendor is working on addressing the issues; however, there is, of course, a point where the lab will need certain issues addressed before being able to move forward - this is where the third case can be especially problematic.

Second, this brings us to the “restarting” portion of the discussion in that thread. In general, if the issues raised can be addressed in a timely manner and based on the version of the product at that moment going through validation, then there should be no “restart” issue. However, if the issues raised take a long time for the vendor to fix and/or require a switch in the version of the product such that the new version includes a large number of other changes in the product (e.g., a switch to a new version of the product with a whole suite of new features), this could cause a “restart.” I generally think of these restarts coming in these two forms.

1. The lab can no longer move forward with the effort while waiting on the vendor to address issues, so the project is put on hold. Depending on time frame here, lab resources will be moved elsewhere and lab knowledge of the product will deteriorate. When the vendor is ready to start back up, the lab has to restaff the effort, rebuild its knowledge of the product and the validation effort, and generally kick things off again.
2. The changes were rolled into a new version of the product, and this new product is dramatically changed from the one that began the validation effort. The lab will have to figure out what has changed and determine how much of their work performed to this point can be reused, much like in a revalidation scoping but more awkward. If this is in combination with 1, this could get close to starting over.

Needless to say, you want to avoid going down this road.

-

Since I mentioned TrueCrypt in a previous post, look at this.

HotPlug allows you to seize and move a computer without losing power. (Video demos.) See also: MouseJiggler.

Yep, you guessed it.

How to circumvent Whole Disk Encryption
The key: Do not allow the encryption to activate. Low level encryption such as Vista’s Whole Disk Encryption (WDE) can halt an investigation. Use HotPlug and Mouse Jiggler to prevent encryption technologies from activating. If you can carry away the computer while it’s still logged in, you maintain full access to the hard drive.

In short, the plaintext key is often stored (cached), or authorization to access the plaintext key is stored (cached), in volatile memory (e.g., RAM) when using things like full disk encryption, so that data read from/written to disk can undergo transparent (to the user) processing. When the computer is powered down, goes to sleep, etc., assuming the hardware/software properly handles things, the (easy) access to the plaintext key is lost (e.g., the cached key or authorization to use the key is wiped). This gear is meant to prevent the circumstances that cause that wiping from happening.

Think of TrueCrypt - if you are using system disk encryption on your home desktop, then you know that, once you have entered your password at boot, the stored encrypted key is decrypted and the plaintext key is then stored in memory by TrueCrypt to transparently encrypt/decrypt data as it is written to/read from disk (i.e., you only enter your password once per boot). Anyone taking control of your desktop at that point has full access to your encrypted drive. However, if you pulled the plug, then the plaintext key would be lost. Well, this gear allows an attacker to grab your desktop and remove it from your home without it losing power (or hibernating).

-

Now this phenomenon sounds a little familiar.

Over 90% of people responded physically, for example with an exaggerated stare or a wave. Almost half responded verbally – more men than women. Here, says Professor Shuster, the sex difference was striking. 95% of adult women were praising, encouraging or showed concern. There were very few comic or snide remarks. In contrast, only 25% of adult men responded as did the women, for example, by praise or encouragement; instead 75% attempted comedy, often snide or combative as an intended put-down.

I mentioned this impact with regards to attire in this post.

(Side note, I have an old, bright red Futura t-shirt that says “For love or money”. With many, it generates mostly “for love!” comments and generally leads to conversation about values and the like. With others, it often inspires awkward mockery, as is the case with almost any loud attire.)

The “others” here are generally straight men showing negative interest, while the “many” are usually straight women or gay men showing positive interest. Perhaps this makes sense, as I am likely viewed as a potential rival to the former and a potential suitor to the latter.

Whatever the case may be, I always enjoy hacking peoples’ thoughts and behavior with something so simple as a t-shirt. As such, my custom t-shirts often play to this effect quite nicely.

-

Speaking of impact,

ABC2 has obtained new video of Baltimore police officer Salvatore Rivieri in action at the Inner Harbor. This time he confronts Billy Friebele, an artist from Washington D.C., who was videotaping at the Harbor last summer.

Friebele told ABC2 he was taping the reactions of passersby to a box he was moving with a remote controlled car. Officer Rivieri is seen on tape kicking the box off of the car and then kicking the car. The officer then orders Friebele to leave the area.

Small world. I knew Billy back in college.

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.

I am caught up in a few things, but I thought some quickies might be nice.

***

Lets begin with sort of FIPS 140 news…

-

The FIPS 140-2 Implementation Guidance has been updated.

[01-24-2008] Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program [ PDF ] has been updated

New Implementation Guidance:

* 7.7 Key Establishment and Key Entry and Output

Updated Implementation Guidance:

* G.2 Completion of a test report: Information that must be provided to NIST and CSE
o Added reference to CMVP comments document.
* G.8 Revalidation Requirements
o Added reference to the CMVP FAQ in change scenario 1.

[01-16-2008] Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program [ PDF ] has been updated

Updated Implementation Guidance:

* G.13 Instructions for completing a FIPS 140-2 Validation Certificate
* 1.8 Listing of DES Implementations
* 7.1 Acceptable Key Establishment Protocols
* 9.4 Cryptographic Algorithm Tests for SHS Algorithms and Higher Cryptographic Algorithms Using SHS Algorithms

There are two key updates to look at here, which finally explain in public, written form what has been lore for quite some time.

The new 7.1 IG provides a detailed explanation the key distribution versus key input/output for FIPS 140-2. I can’t say the explanation is the friendliest, but it is good to see the information out there now.

The update to 7.7 basically finishes the translation of the key establishment requirements into something concrete. And, Appendix D now points here.

Also, I always assumed what the change to 9.4 specifies, but I guess this wasn’t explicit until now.

-

An update to the SHA3 candidate implementation C API has been published by NIST.

Revision 3: January 24, 2008

This document specifies the ANSI C interface profile for implementations of SHA-3 candidate algorithms. C implementations shall support the syntax and parameterization of the interface profile messages as described in this API. The API consists of a few data definitions and one function to compute hashes. The function specified in this API has return values listed that are largely used to supply error codes in the event of incomplete execution of the routine. The error values listed are not meant to be an exhaustive list. If additional error codes are useful for your implementation, please provide them.

Update: I figured I would insert this here, rather than in a separate post.

Submissions for the NIST SHA-3 contest are required to include test vectors that can be used to help to verify the correctness of implementations of the candidate algorithms. A specification has been published with the requirements.

Each submission package is required to include Known Answer Test (KAT) and Monte Carlo Test (MCT) values, which can be used to determine the correctness of an implementation of the candidate algorithm. Values shall be included (at a minimum) for each of the four minimum required hash sizes: 224, 256, 384, and 512-bits.

These KAT and MCT tests are based on tests specified in The Secure Hash Algorithm Validation System (SHAVS) [SHAVS], which describes tests for the SHA-2 family of hash functions. Each of the tests for which values are required in the submission packages is described below. In addition, example files are included which specify the exact syntax and format that submitters are required to use when submitting their KAT and MCT values.

Anyone that has undergone algorithm testing for SHA-1 or any of the SHA-2’s will be familar with these types. However, there is an additional test added into the mix, besides the usual SMTs, LMTs, and MCTs.

To test an algorithm’s ability to process messages longer that 232-bits in length, the candidate must supply a message digest for one extremely long sequence. The sequence is a 64-byte character string repeated 16,777,216 times. The message will be supplied in a file called ExtremelyLongMsgKAT_{Length}.txt for each of the required hash length.[...]

So, it looks like we will be running XLMTs in the future too.

(I guess while I am writing this, I should also note that the C API for candidate algorithm implementations has been updated since I wrote the initial post.)

-

Oh, and NIST is running a workshop on IBE.

June 3-4, 2008

This workshop brings together academia, government and industry to explore innovative and practical applications of pairing-based cryptography. Pairings have been used to create identity-based encryption schemes, but are also a useful tool for solving other cryptographic problems. We hope to encourage the development of new security applications and communication between researchers, developers and users. In addition to presentations, the workshop will facilitate panel discussions among invited experts and workshop participants.

***

Besides the many tumbles taking place, banks have had lots of security news of late…

-

Foiled, but popping through physical and people security is a favorite of mine.

The device, which police described as “sophisticated and requiring great (technical) skills,” had apparently been installed during a previous break-in, during which nothing had been stolen from the bank.

-

It looked like looking the part struck again at a bank.

On Wednesday, a man dressed as an armored truck employee with the company AT Systems walked into a BB&T bank in Wheaton about 11 a.m., was handed more than $500,000 in cash and walked out, a source familiar with the case said.

It wasn’t until the actual AT Systems employees arrived at the bank, at 11501 Georgia Ave., the next day that bank officials realized they’d been had. “When the real security guards showed up is when it became known,” said Richard Wolf, a spokesman with the FBI’s Baltimore division.

Or not. Now, it sounds like an insider job.

Assistant State’s Attorney Marybeth Ayres named Elizabeth K. Tarke, a teller at the BB&T branch, as a possible ringleader. Detectives have linked Tarke with Thursday’s theft at a Wachovia branch in the District, Ayres said.

Detectives talked to other employees and grew dubious about Tarke’s story, Pak wrote. Other employees said they saw no “AT” patch on the man’s clothing, just an all-black outfit, with a black hat, gun belt and semiautomatic handgun. They also didn’t see a badge, Pak wrote. Bank video corroborated their accounts, according to the charging documents.

-

Speaking of insiders at a financial (and ignoring write-down scapegoat theories for the moment), this sounds stunning.

The bank identified the trader as Jerome Kerviel. Mr. Kerviel, 31, joined Societe Generale in August 2000 and was working as a trader on the futures desk at the bank’s headquarter near Paris. He was in charge of futures hedging on European equity market indices, known as “plain vanilla” futures. The bank said he was able to dupe the bank’s own security system because he had inside knowledge of the control procedures gained from previous jobs with the bank.

Though Societe Generale says it first learned of what it termed “massive fraudulent directional positions” on Jan. 19, it waited until it could close out those trades before going public with the problem. Winding down the trades, the bank said, resulted in a €4.9 billion write-down, making it potentially the largest loss ever from an alleged rogue trader.

-

Somewhere else, a little online recon strikes at a bank.

A fraudster walked into a branch of Barclays Bank posing as its chairman Marcus Agius and managed to walk out with £10,000.

The conman is believed to have found Mr Agius’ details online and persuaded call centre staff into issuing a Barclaycard in his name.

***

Finally, some miscellaneous items…

-

I mentioned smell before. Well, here is some more.

After the men were allowed to change, 49 women sniffed the shirts and specified which odors they found most attractive. Far more often than chance would predict, the women preferred the smell of T-shirts worn by men who were immunologically dissimilar to them. The difference lay in the sequence of more than 100 immune system genes known as the MHC, or major histocompatibility complex. These genes code for proteins that help the immune system recognize pathogens. The smell of their favorite shirts also reminded the women of their past and current boyfriends, suggesting that MHC does indeed influence women’s dating decisions in real life.

And,

After the men were allowed to change, 49 women sniffed the shirts and specified which odors they found most attractive. Far more often than chance would predict, the women preferred the smell of T-shirts worn by men who were immunologically dissimilar to them. The difference lay in the sequence of more than 100 immune system genes known as the MHC, or major histocompatibility complex. These genes code for proteins that help the immune system recognize pathogens. The smell of their favorite shirts also reminded the women of their past and current boyfriends, suggesting that MHC does indeed influence women’s dating decisions in real life.

Fear not would be social engineers, we already hack this system.

Since the 20th-century hygiene revolution and the rise of the personal-care industry, however, companies have pitched deodorants, perfumes, and colognes to consumers as the epitome of sex appeal. But instead of furthering our quest to find the perfect mate, such products may actually derail it, say researchers, by masking our true scent and making it difficult for prospects to assess compatibility. “Humans abuse body smell signals by hiding them, masking them, putting on deodorant,” says Devendra Singh, a psychologist at the University of Texas. “The noise-to-signal ratio was much better in primitive society.”

Oh, and don’t assume that smelling “good” is always the way to go. For example, say you want some space on a crowded subway.

-

Remember this?

The DHS is funding security audits of many commonly used pieces of open source software, as noticed by Schneier here and described in eWeek here, from which the following excerpt was taken.

If these [1,2] articles are about the same effort, apparently a bit of low-hanging fruit was removed as a result, as noted in this press release.

All the software scrutinised was found to have significant numbers of security flaws, Coverity said on Wednesday. Since 2006 the project has helped fix 7,826 open source flaws in 250 projects, out of 50 million lines of code scanned, the company said.

For instance, 236 flaws were uncovered in 450,000 lines of Samba code, of which 228 have been corrected.

So, now some open source projects are moving on to the next version Coverity’s static analysis tool.

Projects at rung 2 of the Scan ladder have access to a significant upgrade of Coverity Prevent. The first projects to use these new capabilities report a significant increase in the number of identified defects, with some finding as many as 100 new hard-to-find defects than identified in rung 1 of the Scan ladder.

Anyway, I have no idea of what significance the bugs detected by the scans were, but these extra eyes seem like a good thing in general, as does ~7800 less bugs in this open source software.

-

I found this article quite fun.

The study authors, Dr. Rachel C. Vreeman and Dr. Aaron E. Carroll, said that while doctors realize good medicine requires them to constantly learn new things, they often forget to reexamine their existing medical beliefs. “These medical myths are a lighthearted reminder that we can be wrong and need to question what other falsehoods we unwittingly propagate as we practice medicine,’’ wrote Dr. Vreeman and Dr. Carroll.

And the material from which the article was derived, from which I can quote a concise list of the “medical myths” explored.

• People should drink at least eight glasses of water a day
• We use only 10% of our brains
• Hair and fingernails continue to grow after death
• Shaving hair causes it to grow back faster, darker, or coarser
• Reading in dim light ruins your eyesight
• Eating turkey makes people especially drowsy
• Mobile phones create considerable electromagnetic interference in hospitals.

“Food coma.”

-

Lastly, I poked my head in on this.

Replicant

Dates: January 10–February 9, 2008
Opening: February 17, 2008
Location: 526 West 26th Street – 4th Floor – Room 416 – New York, NY
Gallery Hours: Tuesday to Saturday 11 am – 6 pm and by appointment

Virgil de Voldère is proud to present Replicant, a group exhibition of four emerging artists. Rather than brood over a technocratic dystopia, herald clean utopian spaces, or take a reactionary stance on biological and environmental issues such as climate change and bioengineering, this exhibition explores potential futures in which imagination, adaptation, and creativity present a positive view of cultural and scientific progress. The artists—Ian Burns, Shane Hope, Gilles Rotzetter, and Scott Wolniak—are wildly divergent in their mediums and methods: the work is both outsourced and handmade, meticulous and low-tech, highly conceptual and grounded in materials.

If you go, I recommend bringing printout of the linked to page (or related) and plan on spending 10 minutes or so, as it is a small room/exhibition.

I found this article interesting.

“The study suggests that people conscious of the barely noticeable scents were able to discount that sensory information and just evaluate the faces,” Li said. “It only was when smell sneaked in without being noticed that judgments about likeability were biased.”

In other words, awareness of the situation allows a person to adjust their response to suit the situation. There are two key elements at work here - being aware, and effectively using that awareness.

Anyway, this reminded me of Cialdini’s Influence. The attacks of influence are often carried out beneath the radar of the person being attacked. The attacker triggers automatic responses in the person to influence their decisions/behavior, and the actions that hit these triggers go unnoticed at a conscious level by the person being attack at the time of attack, which results in the person being attacked not properly recognizing the level of influence coming from the attacker. Once a person is aware of triggers and/or able recognize attempts to pull triggers, a person can work to mitigate the influence of triggers and/or the responses to triggers.

Side note, I always find this sort of thing interesting with regards to emotions and relationships. We all have emotional triggers, things that set off strong emotional responses. Learning to understand our triggers, and those of the people around us, can go a long way to having healthy, satisfying relationships. And, with such relationships, comes a great deal of our basic security.

-

Speaking of people, this article has been making the rounds.

The artificial intelligence of CyberLover’s automated chats is good enough that victims have a tough time distinguishing the “bot” from a real potential suitor, PC Tools said. The software can work quickly too, establishing up to 10 relationships in 30 minutes, PC Tools said. It compiles a report on every person it meets complete with name, contact information, and photos.

Ok, so, social engineering is nothing new, and love letters have flooded inboxes. But, it got me thinking for a second…

So, I often speak of using real people for people based attacks leveraging things like beauty and charm. However, since real people tend to be a scarce resource, we are quite limited in the number of attacks that can be carried out and, the less attacks we can carry out, the more important each particular attack becomes. For in person attacks, this people cost can reach extremes. On the other hand, if we go virtual, we can come up with all sorts of ways to farm out the people work to reduce its cost.

Coming back to the article at hand, as a potential way to combine this sort of bot and real people, perhaps a bot that bridged conversations serving as a middle man would be interesting. For example, the bot could hang out in multiple chat rooms or web forums, and cross connect conversations. Or, reply to Craigslist ads and link responders.

Of course, with none of the human participants likely to have the agenda of the attacker here, the conversations would probably have less of a chance of being useful to the attacker than result of automated scripts, even if you could effectively pull off the bridging. Oh well.

-

I remember mentioning cell phone tanka a while back. This takes it to a new level.

“I typed it all on my mobile phone,” Rin explains matter-of-factly over the same device. “I started writing novels on my mobile when I was in junior high school and I got really quick with my thumbs, so after a while it didn’t take so long. I never planned to be a novelist, if that’s what you’d call me, so I’m still quite shocked at how successful it’s turned out.”

[...]

Remarkably, half of Japan’s top-10 selling works of fiction in the first six months of the year were composed the same way - on the tiny handset of a mobile phone. They sold an average of 400,000 copies. By August, the president of Goma Books, Masayoshi Yoshino, was declaring in a manifesto that he was determined “to establish this not simply as a fad, but as a new kind of culture”.

My “waiting to be read” book queue is at ~20. As far as I know, none of these books were written on a mobile phone. I really have to get with the times.

-

When you build a technology based on community input and open communication in a medium that lets gossip circle the world at roughly the speed of light, you can’t expect to hide behind a curtain. And, beautifully, the end result is an open study in people, power, and paranoia, with a good helping of “trust me, it’s for your own good” arguments and “shoot yourself in the foot” phenomena.

A couple of choice excerpts from the article,

Meanwhile, Durova continued to insist that she had some sort of secret evidence that could only be viewed by the Arbitration Committee. “I am very confident my research will stand up to scrutiny,” she said. “I am equally confident that anything I say here will be parsed rather closely by some disruptive banned sockpuppeteers. If I open the door a little bit it’ll become a wedge issue as people ask for more information, and then some rather deep research techniques would be in jeopardy.”

And,

This sort of extreme paranoia has become the norm among the Wikipedia inner circle. There are a handful sites across the web that spend most of their bandwidth criticizing the Wikipedia elite - the leading example being Wikipedia Review (http://wikipediareview.com/) - and the ruling clique spends countless hours worrying that these critics are trying to infiltrate the encyclopedia itself.

Now, I partially pointed to this because I know my circles are always amused by this stuff. But, I also wanted to note this.

But he’s not admitting how deep this controversy goes. Wales and the Wikimedia Foudation came down hard on the editor who leaked Durova’s email. After it was posted to the public forum, the email was promptly “oversighted”
- i.e. permanently removed. Then this rogue editor posted it to his personal talk page, and a Wikimedia Foundation member not only oversighted the email again, but temporarily banned the editor.

It ain’t easy blowing whistles. Even in a supposedly open forum such as Wikipedia, the powers that be crack skulls. You know, silence the critics and keep them silent.

Here, that cracking of skulls is figurative. In other venues, it could be literal. Anonymity has its uses.

…

Oh, and in the conclusion of a related article, we have a good summary of what seems to be going on.

“Wikipedia, in its way, is of great benefit to the web community,” he says. “But I’ve also been greatly dismayed that Wikipedia has apparently attracted some intelligent but problematic personalities with ambition, secret personal agendas, and cold, ruthless behavior towards other editors and ideas that they perceive as threatening their power, position, or agendas. What’s disheartening is that Jimbo and the rest of the Wikimedia Foundation not only don’t do anything about it, but they appear to support these charlatans to some degree.”

-

I mentioned the contest previously. Well, here comes the first entrant.

The Google Lunar X-Prize folks held an event at a space investment conference in San Jose to announce their first fully-registered competitor.

Odyssey Moon, a startup based on the Isle of Man, and run by Carl Sagan mentee, Bob Richards and the CFO of  satellite-provider Inmarsat, Ramin Khadem, plans to land a rover on the moon within the next seven years.

Ouch.

A significant flaw in the PRNG implementation for the OpenSSL FIPS Object Module v1.1.1 (http://openssl.org/source/openssl-fips-1.1.1.tar.gz, FIPS 140-2 validation certificate #733, http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#733) has been reported by Geoff Lowe of Secure Computing Corporation. Due to a coding error in the FIPS self-test the auto-seeding never takes place. That means that the PRNG key and seed used correspond to the last self-test. The FIPS PRNG gets additional seed data only from date-time information, so the generated random data is far more predictable than it should be, especially for the first few calls.

I updated this post accordingly.

[...]This means the PRNG is not reseeded after the KAT, so the PRNG ends up seeded with constant self-test values.

A couple of patches [1,2] are available for the OpenSSL FIPS module. The patches boil down to running FIPS_rand_method()->cleanup() after the PRNG KAT and then reseeding the PRNG.

-

In “related to Tor” news, this is a good write-up on recent vulnerabilities in what is often the default Privoxy configuration, including that shipped with the Tor bundle up until recently.

The installed ‘config.txt’ file (’config’ on Mac OS X) had the following option values set to 1:

• enable-remote-toggle
• enable-edit-actions

Additionally, on Windows the following option was set to 1:

• enable-remote-http-toggle

Malicious sites (or malicious exit nodes) could include active content (e.g., JavaScript, Java, Flash) that caused the web browser to:

• make requests through the proxy that causes Privoxy filtering to be bypassed or completely disabled>
• establish a direct connection from the web browser to the local proxy and modify the user defined configuration values

It should be noted that these are not Tor specific attacks on Privoxy and you may want to disable these Privoxy configuration options even in non-Tor environments.

-

SP800-38D, specifying the GCM mode of operation, has been finalized.

Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC has been finalized. This Recommendation specifies and approves Galois/Counter Mode (GCM), an authenticated encryption mode of the Advanced Encryption Standard (AES) algorithm.

I remember superficially comparing GCM and CCM back a few years ago. Both seemed to have a push at NIST, but you knew CCM would go through the vetting process relatively quickly being a combined mode of what was already accepted while GCM would take a bit of time. Well, CCM has been approved for quite a while, and now GCM is finally there too.

-

These [1,2] have been making the rounds. More fun with MD5.

We announce two different Win32 executable files with different functionality but identical MD5 hash values. This shows that trust in MD5 as a tool for verifying software integrity, and as a hash function used in code signing, has become questionable.

We have used a Sony Playstation 3 to correctly predict the outcome of the 2008 US presidential elections. In order not to influence the voters we keep our prediction secret, but commit to it by publishing its cryptographic hash on this website. The document with the correct prediction and matching hash will be revealed after the elections.

-

Speaking of hashing, there is a mailing list for the NIST hash competition.

A hash-forum@nist.gov email mailing list has been established for dialogue regarding NIST’s Cryptographic Hash Workshops and Hash Algorithm Competition. It is an unmoderated mailing list; messages addressed to this list are immediately distributed to all the addresses on the list. Only members are allowed to post messages to the list; however, anyone who wishes to do so may add themselves to the list.

-

A location service by Google relying on cell towers to estimate your location when GPS is not available.

Why the uncertainty? The My Location feature takes information broadcast from mobile towers near you to approximate your current location on the map - it’s not GPS, but it comes pretty close (approximately 1000m close, on average). We’re still in beta, but we’re excited to launch this feature and are constantly working to improve our coverage and accuracy.

-

Finally, I found this somewhat interesting to me.

“The empirical fact is that people will often switch to strategies they never picked before. They couldn’t have learned these strategies by reinforcement” from experienced rewards, says Camerer. In these situations, people use imagined rewards, or rewards that could have been theirs, to guide their decision making. This process, called fictive learning, is similar to the emotion of regret. “Regret is essentially the bodily sensation or name we give to fictive learning when there was a better choice than the one we chose.”