Archive for the ‘Authentication & Identity’ Category

Quickies: dns, tor 0.2.0.x, truecrypt 6, cold boot sw, fips stuff, j-pake

Wednesday, July 23rd, 2008

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.

Quickies: headaches, links, stories, crypto stuff, other

Wednesday, May 21st, 2008

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

entropy, misc

Wednesday, March 12th, 2008

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 = 368 possible passwords.

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

Looking at SP800-90, min-entropy, another measure of uncertainty, for a set of probabilities p1,…,pn is defined as H = -log2(pmax), where pmax is the maximum p in p1,…,pn.

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 pi for each digit of the password, and our Shannon H = -∑ pi log pi = -1 log 1 = 0 and our min-entropy H = -log21 = 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 = -∑ pi log pi = -((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 = -log2(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/(368)=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.

data sets, walks, kdfs, banksy, odds

Wednesday, November 28th, 2007

I heard Lotus Cafe is gone. And, Rififi may not be happy either. Ah, old timers.

-

Say you have data set you wish to release for research purposes but you don’t want the individual people identified (e.g., a medical data base) and thus tied to particular sensitive attributes (e.g., medical conditions). So, you have this data set consisting of what you consider to be sensitive attributes (e.g., medical conditions) and non-sensitive attributes (e.g., social security number, date of birth, zip code). In order to anonymize the data, you strip out the attributes that serve as blatantly unique identifiers (e.g., names, social security numbers).

Now, there is an immediate issue here. The obvious identifiers have been removed, but lets say this data set also contains attributes (e.g., date of birth, zip code) that when linked to external information lead to the identification of particular individuals (e.g., there is only one person with a given birthday in a given zip code, and this information is readily available someone trying to identify that individual in the data set).

This is where k-anonymity comes in. Now, you have already identified the sensitive and non-sensitive attributes, and you have removed the outright identifiers. From the remaining set of non-sensitive attributes, you can then identify those attributes, which are called quasi-identifiers, that could be linked to individuals through correlation against external data sources.

Here we come to one of the key assumptions made in the k-anonymizing process - the sanitizer can identify the attributes in the data set that can be tied to other, external sources. Not only do they have to identify these attributes, but they also have to assess the level of resources required to use those attributes to penetrate the anonymity of the data set, and make judgment calls on modifying the data for anonymity and/or privacy versus the usefulness of the resulting data set. This is hard stuff.

You can see many issues with this assumption. Does the sanitizer really know what will be quasi-identifiers in a data set? Even if they do, are their judgments about the risk posed by those identifiers realistic? For example, the sanitizer might not know about various public records or even google. Another example, one may assume that only large governments would have access to name, date of birth, and zip code information for individuals. However, most of us have access to this information for at least out friends and family.

Anyway, once you have picked out the quasi-identifiers, you then ensure that at least k records in the data set possess the same set of values for quasi-identifiers (e.g., generalize the date of birth to be year of birth, such that at least 10 records turn up for all years of birth and zip code combinations). In other words, instead of being able to uniquely identify a unique record using particular values for the quasi-identifiers, one always ends up identifying a set of k records with any particular values for the quasi-identifiers (e.g., you pull up 10 records at least for every year of birth and zip code combination).

Important note for the paper that follows later in this post: You may be wondering, what happens when dealing with all these sparse data sets with long-tail distributions? For example, a particular attribute may have a large number of values that are unique or at least very minimally spread across records, which could mean huge impacts on the data set if these values were generalized or removed for k-anonymity purposes. Which means there may be a big trade-off between anonymity and/or privacy, and the usefulness of the data here, which will minimize k if not render k-anonymity infeasible in order to keep the data at all useful. And, it is notable that most transactions databases fall into this category (e.g., credit card records, amazon purchases).

But, say k-anonymity is reasonable for the data without too much loss of usefulness of the data. Great, that covers establishing the exact identity of records, but there is an issue here - we may still be able to tie sensitive attributes to individuals. For example, if the sensitive attributes you are trying to unlink from an individual are applicable to all of the k records pulled up by the quasi-identifiers (e.g., all 10 records have the same medical condition), then one can assume that the individual possesses this attribute even if they can’t uniquely identify which of the k records is that individual. Or, if one knows particular sensitive values do or do not apply to the individual, they can rule out those records, perhaps pinpointing the applicable value of the sensitive attribute for the individual concerned (e.g., the medical condition in the group is either a broken arm or severe depression, and one knows the individual does not have a broken arm).

Which leads to the concept of l-diversity, wherein a set of k records should have l number of values for sensitive attributes contained within it. Now, when one pulls up that set of k records, all of those records do not have the same sensitive values and, even if I know certain sensitive values to do/do not apply to the individual in question, there is potentially still a range of records with other values for sensitive attributes that are applicable, making it hard for me to establish exactly which values for the sensitive attributes apply to a particular individual.

l-diversity can result in the data set undergoing significant modifications. Like with k-anonymity, judgment calls must be made on privacy versus the usefulness of the data set.

But, say l-diversity is applicable to the data set without too much loss of usefulness of the data. Nice, but we may still have some semantic ties or non-uniformity that can be exploited. For example, if all the k records have some related values for the sensitive values (e.g., all the medical conditions were mental problems) while the overall data set covered a larger variety of values, then information is learned about the members of k. Or, if the sensitive attributes in k records have one of set of odds of having particular values (e.g., 75% of members have cancer), while in the overall data set the sensitive attributes have some set of odds (e.g., 10% of members have cancer), this can be used to reveal information about the set of k records distinguishable for the overall data set.

Which leads to t-closeness, wherein the distribution of values of sensitive attributes in a set of k records will mimic the distribution of those values across the whole data set within a range t.

t-closeness can result in the data set undergoing even major changes. Like with k-anonymity and l-diversity, judgment calls must be made on privacy versus the usefulness of the data set.

And so forth.

I typed out that summary because I just noted this paper interesting. [via what is left of the cypherpunks list]

We present a new class of statistical de-anonymization attacks against high-dimensional micro-data, such as individual preferences, recommendations, transaction records and so on. Our techniques are robust to perturbation in the data and tolerate some mistakes in the adversary’s background knowledge.
We apply our de-anonymization methodology to the Netflix Prize dataset, which contains anonymous movie ratings of 500,000 subscribers of Netflix, the world’s largest online movie rental service. We demonstrate that an adversary who knows only a little bit about an individual subscriber can easily identify this subscriber’s record in the dataset. Using the Internet Movie Database as the source of background knowledge, we successfully identified the Netflix records of known users, uncovering their apparent political preferences and other potentially sensitive information.

A few paragraphs of note…

Micro-data are characterized by high dimensionality and sparsity. Informally, micro-data records contain many attributes, each of which can be viewed as a dimension (an attribute can be thought of as a column in a database schema). Sparsity means that a pair of random records are located far apart in the multi-dimensional space defined by the attributes. This sparsity is empirically well-established [6, 4, 16] and related to the “fat tail” phenomenon: individual transaction and preference records tend to include statistically rare attributes.

This applies to most of those real-world databases out there containing information about us, which is something to note when policies say that information that could identify you has been removed from a data set before that data set is distributed.

Our de-anonymization algorithms are designed to work against databases that have been anonymized and “sanitized” by their publishers. The three main sanitization methods are perturbation, generalization, and suppression [23, 8]. Furthermore, the data publisher may only release a (possibly non-uniform) sample of the database. For example, he may attempt to k-anonymize the records, and then release only one record out of each cluster of k or more records.
If the database is released for collaborative filtering or similar data mining purposes (as in the case of the Netflix Prize dataset), the “error” introduced by sanitization cannot be large, otherwise its utility will be lost. We make this precise in our analysis. Our definition of privacy breach (see below) allows the adversary to identify not just his target’s record, but any record as long as it is sufficiently similar (via Sim) to the target and can thus be used to determine its attributes with high probability.

The tradeoff between privacy and/or anonymity, and usefulness comes into play, and the authors make sure to take advantage of it. The real-world is a fun place.

Moreover, the linkage between an individual and her movie viewing history has implications for her future privacy. In network security, “forward secrecy” is important: even if the attacker manages to compromise a session key, this should not help him much in compromising the keys of future sessions. Similarly, one may state the “forward privacy” property: if someone’s privacy is breached (e.g., her anonymous online records have been linked to her real identity), future privacy breaches should not become easier. Now consider a Netflix subscriber Alice whose entire movie viewing history has been revealed. Even if in the future Alice creates a brand-new virtual identity (call her Ecila), Ecila will never be able to disclose any non-trivial information about the movies that she had rated within Netflix because any such information can be traced back to her real identity via the Netflix Prize dataset. In general, once any piece of data has been linked to a person’s real identity, any association between this data and a virtual identity breaks anonymity of the latter.

Anonymity tends to be a one way street. This can be particularly dangerous when it comes to persistent pseudonyms.

We have presented a de-anonymization methodology for multi-dimensional micro-data, and demonstrated its practical applicability by showing how to de-anonymize movie viewing records released in the Netflix Prize dataset. Our de-anonymization algorithm works under very general assumptions about the distribution from which the data are drawn, and is robust to perturbation and sanitization. Therefore, we expect that it can be successfully used against any large dataset containing anonymous multi-dimensional records such as individual transactions, preferences, and so on.
An interesting topic for future research is extracting social relationships, networks and clusters from the anonymous records. This knowledge can be a source of information for further de-anonymization [13]. In the case of the Netflix Prize dataset, de-anonymization of individual records may also have interesting implications for winning the Netflix Prize. We discuss this briefly in appendix B.

Data is recorded, filtered, and mined. You, your actions are not random. There will be non-uniformity, patterns. Identities and attributes will always appear.

I tend to think pseudonymity is the best you get in practice, and even that is quite difficult.

-

So, a while back I wrote this.

Side note, this is even more interesting in combination with things like the reality it generally takes couples trying to have a baby on the average of a few months to achieve pregnancy. Such drawn out periods seems to protect against a number of attacks, such as misrepresentation and quick judgement - for example, it exposes potential mates that seem good at first glance but aren’t quite so good once a closer look is provided.

Fitting right in here, I noted this.

However, Provost and her colleagues say there is in fact no contradiction between this research and other studies, as they are investigating two different kinds of signal. The previous research investigating men’s response to fertile women focused on signals such as smells and facial expressions, which can only be detected at close range. That makes evolutionary sense, as it would benefit a woman to advertise her fertility to a man that she has decided is worth having children with and has therefore allowed to get close to her.

In contrast, men can pick up on the attractiveness of a woman’s walk from long distance, and it can therefore act as an unwitting signal to less appealing males who she might not want to choose. So the advantage of having a less sexy walk around the time of ovulation becomes clear: it allows a woman to hide her fertile period from undesirable men who might take advantage of her at that time.

-

I noticed this request.

As many of you know, NIST has specified two standard KDFs for use with key agreement algorithms (e.g., Diffie-Hellman or MQV) in NIST SP 800-56A. NIST is considering supplementing the 800-56A KDFs with a more broadly applicable KDF. In particular, NIST is considering a proposal for an HMAC-based KDF. Before committing resources to this effort, we would like to get a better handle on the requirements seen by protocol developers and evaluate the level of support for such a standard. We would also like to identify alternative designs that should be considered.

PBKDF2 (something you may already use possibly without knowing it) and S2V were pointed to in replies.

-

Look at that, Banksy in New York.

VANINA HOLASEK GALLERY·502 West 27TH Street New York, NY 10001 T: 212-367-9093

FOR IMMEDIATE RELEASE:
BANKSY DOES NEW YORK
DECEMBER 2ND – DECEMBER 29TH, 2007
OPENING RECEPTION: SUNDAY, DECEMBER 2ND, 1 PM -5 PM

BANKROBBER GALLERY, London, in collaboration with VANINA HOLASEK GALLERY, are pleased to present for the first time in New York, an exhibition of works by Banksy, on view from December 2nd through December 29th, 2007.

There may even be a comment on security in here.

He’s the maniac who got on the news for managing to smuggle one of his pieces of art into Tate Britain and embarrassed everyone because nobody seemed to notice…He’s the wit behind the stencilled “Mind the Crap” writing that appeared overnight on the steps to Tate Modern. He is the prankster who smuggled 500 alternative copies of the Paris Hilton CD into record stores. He is the subversive who placed a life-size replica of a Guantanamo Bay detainee in Disneyland. He’s the jester who gave LA a painted elephant. He is the trickster whose hoax cave painting of a man pushing a supermarket trolley sat in the British Museum unnoticed for three days. He is the infiltrator who disguised as a pensioner hung his perfectly framed pieces in the Metropolitan, MOMA, Brooklyn Museum and his “dead beetle with glued on sidewinder missiles and satellite dish” had pride of place in the Museum of Natural History NYC. Get the picture, get this. Banksy images are even being used to sell 900k condos in Williamsburg.

Anyway, there is a party Saturday (2007-12-01) night from 6-9pm at the gallery celebrating the opening. [via thisheartsonfire]

-

Finally, here are some generic odds.

The National Safety Council has been compiling and reporting on injury data every year since the 1920s. The table below was prepared in response to frequent inquiries to the Council concerning the odds of dying from or being killed by a specific incident or occurrence such as a lightning strike or a plane crash.

The odds given below are statistical averages over the whole U.S. population and do not necessarily reflect the chances of death for a particular person from a particular external cause. Any individual’s odds of dying from various external causes are affected by the activities in which they participate, where they live and drive, what kind of work they do, and other factors.

Diner, petnames, misc

Tuesday, October 30th, 2007

Ok, as it has been a while since I last posted and will probably be some time until I next post, lets do two posts in one day. This one is just some miscellaneous items.

-

(Thats “diner” in the title, not “dining cryptographers and their problems”…)

I rarely talk about customer service with regards to places to eat. The main reason for that is I generally eat in my local neighborhood, and I learned a while back that talking about places you can be found reliably on a blog is not always the smartest thing to do.

That said, there is one diner in Manhattan that I make a point of swinging by quite often, namely Cheyenne Diner. Great customer service, including my absolute favorite waitress in Manhattan (I don’t think I have actually had to order for myself in over a year - my food just appears). Quality food and lots of it on the cheap. Open 24 hours, so perfect for a late night person (like me). Just an all around great experience.

Anyway, while I think I may be the only NY resident that absolutely loves this place, at least someone else has noticed it. (Unfortunately, the articles at the referenced site do not have separate links. Perhaps this will end up being the archive page for this month.)

On the block: Top 10 New York Classic Diners, a list of the best New York diners that haven’t changed much at all (including prices, interiors, and staff) in the last 20+ years. What you pay for one drink at some new fancy bar will get you a full meal (with bread, salad, and a side, of course!) at most of these places.

[...]
9. Cheyenne (Midtown West)

It is on the corner of 33rd st and 9th ave, a few blocks from Penn station (for those of us coming from, say Bayside :) ). Being smack dab in the middle of mid-town, you find locals, commuters, and tourists alike pop in.

Needless to say, highly recommended. I always end up there some time well into the nightshift, and I can’t say enough good things about the late night staff.

-

This is a petnames plugin for Firefox. [recently resurfaced in this mailing list post]

It reminded me of an old post. I pointed out using your bookmarks and commented on an SSH style of bookmark where public keys (in certificates) were part of it. I also noted that such a thing might not mean anything to average end users over a regular bookmark, which was the tricky part.

Attacks based on user ignorance of anything to do with PKI or TLS will apply regardless of “high assurance” certificates or not. What really matters here is whether or not browser security indicators matter to users (e.g., do users know about the security indicators provided by a browser, what the indicators mean, and what should be done in response to the indicators?).

    […]verifying that you are in fact establishing an SSL/TLS session with the proper entity.[…]
    […]countering an SSL/TLS MITM attack.[…]
    This is an active research area. Petnames have been proposed, which I like (think PGP web of trust in some form). This has similarities to the SSH-type trust model, which has also been proposed and which I also like. In recent minutes to an IETF-PKIX meeting, the Opera people were looking at “extended validation” certificates. There has been all sorts of talk, pros and cons, about “high-assurance” certificates.

In this regard, while I like the idea of bookmarking a web site and its certificate(s), how exactly to inform a user that a certificate is changed, and establishing what actions a user should take in such a case, is the hard part. Every model I envision reduces to checking the digital certificates when the certificate presented is different from the one that is bookmarked, and then all the same problems come back into play - you might as well have just bookmarked the web site and left out the certificate.

So, I like the petnames plugin for Firefox, and I think most people familiar with the SSH way of doing things would be comfortable here. The plugin adds another layer to the advice provided here, and works well for me at least.

Bookmark web sites that you visit, especially where you conduct transactions like buying stuff, and then return to those sites only through your bookmarks (this is like what we do with server public keys in SSH). Now, when you receive that email, instant message, or embedded link in some rogue web site purporting to be from, or purporting to point you to, Paypal and you really do feel it necessary to log into Paypal in response, don’t follow any of the links provided - instead, use your bookmark for the Paypal web site. It doesn’t solve all these problems, but it helps quite a bit.

-

But, it looked real… [via the gold-silver-crypto mailing list]

Evidently, no one at Minnesota-based Supervalu bothered to confirm the authenticity of emails sent in late February. Purporting to come from two of the company’s suppliers, the messages instructed Supervalu to wire all future payments to new bank accounts. One email purported to come from representatives of Frito-Lay and the other from American Greetings. Both suppliers have established relationships with the grocery chain.

The emails were phony, but within two days, Supervalu began moving money into the accounts. Over the course of a week, the company transferred $10,128941.94 in nine separate payments. [...]

These kids have become my standard quote for this.

Teen #1: Hey, man, I think we should get our important stuff laminated. No one ever questions lamination.

-

Short article (behind a paywall) about talking tech to the non-techie.

Technology is very complex and intimidating, and technology folks are constantly getting knocked for poor communication and poor customer-service skills. It’s taking a lot of time, leads to a lot of frustration, and leads to a lot of money being misspent.

This brought to mind one of the core reasons I originally founded D-kriptik and the original point of this blog - bridging tech and non-techies. Customer service is still at our core, but we have wandered a bit off the general IT support course.

-

Perhaps its the Trek in me, but this reminded me of transparent aluminum.

By mimicking a brick-and-mortar molecular structure found in seashells, University of Michigan researchers created a composite plastic that’s as strong as steel but lighter and transparent.

Rambling authentication

Thursday, April 19th, 2007

A few random thoughts about authentication. I tell stories too, as people seem to like those. I think my previous post inspired this. And, I was poking around at SPKI a couple of weeks ago too. Anyway, there is no point, and I could be totally off base. This is just a ramble.

-

I was thinking about meatspace identification and authentication. It seems we, as people, utilize the characteristics that identify us to also authenticate us, such as our biometrics, styles, etc., in meatspace.

So, we have -

  1. Identifier - the combined attributes that serve to distinguish an entity from other entities. For example, my face, way of speaking, body language, etc. all come together to make me different from everyone else.
  2. Authenticator - possession of these unique attributes serves to authenticate an entity’s identity. For example, only I can have my face, way speaking, body language, etc., and so these serve to authenticate me as possessing my identity.

(I am implying uniqueness here, but that is not necessarily at the individual entity level. For example, identifying and authenticating someone as a police officer requires a unique set of attributes that only police officers are supposed to possess.)

There are two important notes here -

  • The identifier and the authenticator are the same.
  • The identifier and the authenticator are public.

The reason the identifier and the authenticator can be the same is that the authentication mechanism, that is, our ability to take this information presented by an entity and use it to confirm that an identity is bound to said entity, makes it difficult to create forgeries of the identifier/authenticator. This may not always be the case though. For example, if you see someone once briefly across a room, you may not be able to identify them again reliably - there has not been enough time to train your authentication mechanism with the person’s information.

Also of note, we may assume many different identities. For example, your identity at work might differ completely from your identity at play - in fact, people from the one context might not recognize you in the other. (I know some people don’t like it, but I sometimes refer to such identities as pseudonyms.)

Moving along, we have these identities. Now, we can build reputations for these identities based on our interactions with, and observations of, these identities, or based on feedback from other identities. We can assign properties to these identities. These identities provide a means for accountability.

Let me illustrate all this with an example of something that happened to me recently…

There are two parties on Saturday night that I normally attend in secession. One is a rock, new wave, electro gig, the other is a deep house after hours. I normally sit back and soak the atmosphere at the former, while I run around dancing at the latter.

One night, a group of people from the new wave party ended up at the deep house party. When they saw me, they came running over and expressed the following.

  • They “knew me” from a few parties. (No, I did not know them.)
  • They were surprised to see me at the deep house party. They did not think that was “my thing.”
  • They were shocked to see me dancing. They did not think that I danced.
  • They were nervous about the crowd at the deep house party. Seeing me made them feel both comfortable and safe.

So, I mentioned assigning properties to entities. My example above illustrates some such properties built from my reputation. Probably a much more obvious property is names. We call people Alice and Bob. As more people come about, longer names come about, or names and locations. You call someone Bob Alice, or refer to Bob from the area Eve.

And, we can bring in third parties to link these properties to us. In my example above, people directly tied properties to me, and could have conveyed these properties to others. Another example comes in the form of IDentification (ID) issued by third parties, like governments or insurance companies, that bind us to properties we possess.

So, I bring up IDs. Now, think about what those IDs in your pocket let you do. An ID authorizes me to drive a certain type of vehicle. An ID can link me to a name and address that can be used to locate me can in order to provide physical accountability. An ID can link me to a particular age in order to for an establishment to determine if I am old or young enough to enter. And so forth.

This is important. Notice what IDs are used for - linking specific properties to an identity. IDs don’t identify us - our faces, etc. do that. Rather, IDs identify properties we possess.

Ok, so now enter into cyberspace.

  1. Identifier - a unique label that distinguishes an entity from other entities in a system. For example, a unique number assigned to me.
  2. Authenticator - possession of something, or multiple somethings, whether a secret, a token, fingerprint, etc., that serves to authenticate an entity’s identity. For example, proving possession of a secret character string that is associated with a username.

There are sort of two important notes here -

  • The identifier and the authenticator are different.
  • The identifier may be public, but the authenticator is kept secret or difficult to forge or both.

In cyberspace, we use external identities, as we, people, cannot physically enter into cyberspace at this time. And, in the digital world, creating copies is trivial. By virtue, if an identifier, which is public, is the same as an authenticator, which would also then be public, then an entity could just copy the identifier/authenticator and assume the identity.

Herein lies what I think is an issue when translating authentication mechanisms from the people world to the digital world. People are used to identifiers being the same as authenticators in many circumstances, so the separation of the two makes for a difficult conceptual leap. For example, if a web site looks a bank’s web site, most people will interact with it like it is a bank’s web site. That is how they both identify and authenticate the site. Sure, fraudsters can look the part in real life too, but the digital world lends itself to copies and scalability.

Another difficulty is that there is confusion about just what ID provides in meatspace. We use ID differently than we think we use ID. Unfortunately, when we come to the digital world, we try to map how we think we use ID to how we use ID. For example, a web site presents me a certificate saying this site’s name is its name. But, often we don’t care about names, we care about the accountability of the operators of that web site. That certificate says nothing meaningful to us about that accountability. On the other hand, looking at your driver’s license and establishing your name and address does say something to me about your accountability.

It should be noted that identifiers and authenticators from meatspace and cyberspace come together frequently enough. For example, IMers get quite good at recognizing each other’s mannerisms, such that they can spot when someone other than the usual entity has assumed a particular handle. Biometric authentication in digital systems works in much the same way, although the authentication algorithms may be a bit less sophisticated than people’s internal algorithms.

The following serves as an example of identity, authentication, and reputation…

I have had a number of nyms that have had very distinct reputations. Some used digital signatures to bind messages to an identity, others used content, and others used both. Which worked better really depended on who I was communicating with - for example, cypherpunks probably understand public key crypto but people on a jazz mailing list may not (the latter is an assumption based on complaints a friend of mine used to make about the technical competence of people on a jazz mailing list).

Anyway, for one nym that used both digital signatures and content to establish its identity, I signed all messages with a particular PGP key and used the same person to rewrite my messages. One time, when the person I used to rewrite my messages was unavailable, I asked someone else to fill in, and I signed the end product with the same PGP key. That message resulted in paranoia flying about that the nym had been compromised, etc., and that nym never really recovered. Still, I kept the nym around so as to be able to spark more paranoia every once in a while. ;)

Bands, banks, and what not

Tuesday, April 10th, 2007

I started this post a couple of days back and then got tied up with work before I actually posted it. I guess I could edit it some more, but this is just a blog anyway. :) So here goes.

I was reading this post over at 1 Raindrop.

Bands = Wired, Factors = Tired, Passwords Only = Expired

IT Security groups so often end up in drilling down one particular rabbit hole that they lose sight of the big picture. Sometimes some basic authN schemes from multiple communication bands will add more strength than increasing the strength of a single component.

First thing that popped into my head, OOB. Remember this post?

The general idea is that I send my OpenPGP public key to my buddy via, say, email. Now, my buddy has no way of knowing whether the key received via email is actually from me - for example, someone else could have sent them a OpenPGP public key and claimed it was from me, or someone could be sitting in between us and replaced my key with their own. So, I call my buddy (or vice versa) and read off the key’s fingerprint while my buddy verifies that the key received has that fingerprint, usually by visually matching what I am reading off.

Anyway, I took away three points from the overall discussion and the examples given. One had to do with bands, but the other two had to do with authentication and notification.

Point 1: Authentication matters. Knowing identifying information is not the same authenticating; however, identifying information can be used for authentication if it provides a means to confirm that identity. The authentication itself would be the act of performing that confirmation. For example, someone that knows my name, birthday, SSN, phone number, and address is not necessarily me and should not be allowed to carry out actions in my name; however, if my address or phone number can be verified in some manner, then sending me a letter, or giving me a phone call, asking for confirmation of actions attempted in my name could serve to authenticate/authorize those actions.

The value of an identity comes from three items that can be tied to an identity - reputation, accountability, and access control. Authentication binds an identity to an entity, which allows for reputation, accountability, and access control of that entity.

Point 2: Notification matters. Even if someone has obtained the ability to conduct some action in my name, if I was notified of said action, even after the fact, then I could appropriately react to it. For example, credit card statements provide this ability to me for credit cards I know of, as I can audit the statements at the end of the month or online and dispute fraudulent charges. If people performed the same type of monthly (or more often) check on their credit reports, the window of opportunity for an attacker to gain credit in one’s name and utilize said credit is greatly reduced.

This feeds back to the accountability (and reputation) of an identity, providing an entity knowledge of actions being attempted under that entity’s identity.

Point 3: OOB communication can provide a convenient way to increase the difficulty of attacking a particular system. Piping the control and status information (i.e., authentication information from point 1, or notification information from point 2) on bands separate from data (or other control/status) can be useful for providing, say, defense in depth, as, say, phone companies learned from whistles. For example, say all online banking transactions resulted in a phone call to my home before the transaction would be performed. Just compromising my online banking account or my computer is not necessarily (skype anyone?) enough to rob me now. However, an easy design flaw could happen here too - say, if instead of all online banking transactions requiring call confirmation, only monetary one’s do. If changing one’s home phone was an online banking transaction capability, then an attacker could simply change the phone number to something under their control and then perform a monetary transaction.

Anyway, the real point of this post is to allow me to reference a story I wrote a while back, which was rejected from Daily Dave, but has now found a home in this blog.

Date: Wed, 10 May 2006 20:48:18 -0400
From: xxxxxxxx <xxxxxxxx@xxxxxxxx.xxx>
[...]
CC: dailydave@xxxxxxxx.xxxxxxxx.com
Subject: Re: [Dailydave] Scam artists, your web browser, and you
[...]

On 10 May 2006 10:50:10 -0400, Dave Aitel wrote:
> I called up the credit card company
> and told them the story and they said “Well, whatever. Just tell us if
> they charge you”.
>
> See, this is why I don’t get carding and the big fuss over it. I’m not
> liable for that money, and the credit card companies clearly don’t
> care if I hand my number out to the world.

I had a similar experience back a few years ago. I was looking at the charges posted to my account, and there was some random $50 charge on there from a few days back. I had not bought anything with that credit card number a few days back, so I called up the credit card company and let them know.

The credit card company wanted to confirm that I was not forgetting that I had made a purchase, so they called up the company that charged my card while I was on the line. It turned out to be a mail order pet supply shop, and the charge was for some sort of specialized dog food. I did not have any dogs at the time, but, even if I had, I would not have been mail ordering dog food.

Besides getting the details on filing a dispute, I asked for my account’s credit card number to be canceled and a new one issued. The credit card company explained to me that this charge might be a freak occurrence and asked me if I sure I wanted to get a new card. I was quite sure.

Some time later, I received a call from a cruise company letting me know that my (now canceled) number had been declined for a thousand dollar charge and asking me for new billing information. Needless to say, it was not me trying to take a vacation.

-

I can’t say this radically changed the way I used credit cards, but it did result in me checking my accounts quite regularly online for strange activity and actually looking over the statement received at the end of the month. So far, my vigilance has been for nothing - I have not had any other rogue charges.

My impression is that the credit card companies themselves take the approach of trying to detect unusual behavior on an account and blocking such transactions until the account holder can be contacted for verification. I have no idea how effective the approach is, but I know the credit card companies I deal with have been quite accurate in identifying activity that is way out of the norm for me. (Take that cruise charge above, I can imagine it would have been flagged for verification, if the card number itself have not already been closed out.) I guess the rest of the fraudulent transactions are just consider part of their costs, much like retail stores factor in the cost of shoplifted goods.

-Andrew

So, this sort of verification is already performed by credit card companies in some instances. They call your home phone number and ask you to verbally sign off on transactions they have flagged as suspicious. Besides verification, these types of communications are also used by financial institutions for notification purposes. For example, multiple failed attempts to enter a PIN may result in a phone call, or letter, to your home from a financial institution.

ID checks, search revisited again

Wednesday, March 14th, 2007

I probably sound like a broken record these days, but people are my interest right now. And, one of the things I really enjoy about exploring this area is that you get to meet a lot of people, and hear their takes on the people factor and security. So, while none of the following may be new to you, I found it interesting…

(Of note, this information is for my research purposes, and I am posting it here to foster discussion with some of my readers. Realize that there are real consequences to misrepresenting yourself at ID checks, such as being fined or going to jail. Do not try any of this.)

A couple of days ago, I was riding on the train, when a group of women pulled me into a conversation. Something about my shirt. We got to talking about places to go, and the next thing you know we were talking about ID requirements. Turned out, these ladies were college students and not quite legal drinking age, which is often a prerequisite to entering venues in NYC, and this was the motivation behind the attacks to be discussed.

Now it gets interesting. One of the women in this group actually had a stack of real IDs that were all for people of legal age. The IDs were gathered from friends and family (e.g., older sisters), whether given or taken (e.g., “borrowed without permission”). Basically, what these ladies did was figure out which IDs were the best matches for each of the members of the group, and then each of them tried to pass themselves off as legal age using the selected ID. They noted that the height and eye color listed on NY driver’s licenses was entered by the person getting the license, sometimes input into the system incorrectly, and not at all verified by the issuer. They also pointed out that NY driver’s license would note when a person required corrective lenses or contacts, which mattered since wearing (or not wearing) glasses could change appearance and wearing contacts could change eye color. More interesting though, they discussed how legitimate IDs let a place claim that it did its jobs at the door, as the facial recognition process itself was quite subjective (this made me think of plausible deniability - I told the ladies they should consider politics). Their impression of the effectiveness of this attack at getting them passed the ID check was at about 85%.

In order to up the probability of success, the ladies employed two secondary techniques. One technique was having the most adept social engineers of the group conduct the primary interactions with the ID checker. The ranking of such skills was subjective, but it generally came down to being attractive and social. The point of this was to get the checker in the frame of mind of wanting to allow the ladies to enter, which also implied getting the check to want to accept the IDs being presented. This was also used to avoid any signs of nervousness from the group and get them looking the part. The other technique was just memorizing the details on the ID and being ready for small talk with the ID checker (that applied to everyone, not just the primaries used in the first secondary technique) - such interactions were rare, but did happen from time to time. With these two simple measures in place, their impression of the effectiveness of the attack was at about 95%.

Ok, so these college students had a fairly debilitating attack against these subjective facial recognition ID checks, but it was based on obtaining a number of legitimate IDs - could they get rid of this requirement, bypassing IDs all together? Well, I inquired about what happens when they don’t have IDs. Besides noting that obtaining real IDs was “easy” right now and so there was no reason to make the attack more difficult, there were a few other interesting points they made, which applied both with the legitimate ID attack and without.

One of the keys to success they cited was doing their homework (e.g., reconnaissance). Knowing how strict a place was about IDs, knowing what had worked or not worked in the past, having profiles on the different bouncers (e.g., a “mean” to “nice” scale), having affiliations with particular gatekeepers (e.g., being friends with the doorman), understanding their current ID situation (e.g., did most of the group have real IDs? did none of the group have real IDs?) etc. was all involved here. Their social network was particularly important, as this information was shared among their peers and easy to come by knowing the right people (sounded like the hacker community to me).

These women knew exactly who were the skilled social engineers of the group, and those were the people they set loose on the bouncers. With the homework done, it often came down to these people’s skill sets once out there in the wild performing the attack. They actually pointed to a specific member of the group and said she could get in almost every door, sometimes because of contacts, most times because of personality, looks, and manipulation.

These ladies also understood the impact of beauty. Besides the obvious things like flirting with bouncers, they felt that most places were looking to attract beautiful women, because that in turn attracts everyone else, so places wanted to let them in. Also, they were careful to note here that beauty was important even with the legitimate ID attack, as they felt ID checkers sometimes did recognize the IDs were not really theirs, but, because they were an attractive group of women, it was in the place’s best interest to let the ladies in, given the plausible deniability factor.

Anyway, all of this sounded very similar to my recent ramblings, and so I thought it fitting for this blog. These sorts of attacks are not restricted to age verification ID checks by any means, and I even think the general methodology employed here ports to an extent to how to conduct attacks on systems in general.

-

After a long dry spell, the interesting search terms just keep on coming. It’s not a weekend, but so be it -

how+use+ix+wordpress+2.1.1

LOL. This post might be of interest.

Why+does+physical+beauty+threaten+people%3F

You might enjoy this post. Oh, and cool pseudo-fact - people tend to give beautiful people more personal space than not so beautiful people. I ran into a model last weekend and ask them to put it to the test - people flew out of their way when we walked down the street.

does+being+beautiful+go+a+long+way

You too might enjoy this post.

Quick oldies

Saturday, February 3rd, 2007

A couple of quickies this cold weekend…

-

This briefly popped up on metzdowd crypto.

It is my understanding that SSL is engineered to resist mitm attacks, so
I am suspicious of these claims. I wondered if someone more familiar
with SSL/TLS could comment.

Isn’t in the case that the application doing SSL on the client should
detect what this proxy server is doing and display a warning to the user?

Why write something new when I can just point to an old post, right?

These settings also have nothing to do with countering an SSL/TLS MITM attack. For example, ettercap will gladly negotiate a secure connection with you and with your intended destination server, replacing the intended destination server’s certificate with its own, populated quite fully with the intended destination server’s information. This will generally result in a warning dialog box from your browser, but an attacker could get a certificate signed by a proper authority, and then have that sign the certificate ettercap generates on fly, which means the browser does not even pop up a warning dialog box.

-

Someone pointed me to this.

RainbowCrack-Online enables businesses and individuals to assess their password policies by providing access to our pre-generated hash tables. Now, previously thought secure passwords are often proven insecure. By giving our clients access to the same resources that malicious users utilize we create a level playing field. This enables our clients to develop a pro-active security policy that protects against network intrusions and corporate espionage.

Not new, and once again I can point to an old posts.

This can make precomputing password hashes and building lookup tables more difficult as such efforts will have to incorporate the unknown salts and thus the larger set of password hashes possible per password, and this can increase the effort of cracking multiple password hashes as the same salt needs to be shared between password hashes for the work performed on cracking one password hash to be easily applied to others.

So, how much salt do you think is used by the types of password hashes that these lookup tables have been generated for?

-

For some discussion on the current to near future in content distribution, bandwidth, and the web, this thread on nanog and this thread (and its splits) on SF webappsec might be of interest.

Reminded of bookmarks & fingerprints

Wednesday, May 3rd, 2006

I enjoyed this post on Emergent Chaos.

So, I’d love to hear why, in an era when criminal enterprises are able to forge an entire enterprise, to the extent of developing new products, they won’t do enough to get a high assurance certificate?

True.

Shostak proposed the following solution.

I expect that persistence memory about the certificate, so that your browser alerts you on change, with a design that has been created with the user in mind, and tested on a variety of real users, is the right model.

This brought to mind a few notes from this post on D-kriptik, as excerpted below.

[...]For example, you could establish an SSL/TLS session with a malicious web site that has a domain name that is a variation of, or related to, the name of the site you intended to visit. That site could easily have a proper certificate signed by a browser trusted authority for that domain name, which means the browser does not even pop up a warning dialog box.

(We already see lots of business web sites that use separate payment providers, so when a user goes to checkout, they get redirected to some random payment web site. And, I was recently complaining to someone about bank web sites that have bizarre domains, a couple of which use variations of their normal domain for their online banking. So, people have become accustomed to entering sensitive information under “weird” domains.)

I think this attack will apply regardless of “high assurance” certificates. As Shostak pointed out, getting “high assurance” certificates can make sense for attackers.

In fact, most people have no idea what warning dialogs with relation to SSL/TLS negotiations or digital certificates mean, and, in many cases, they are false alarms anyway. So, virtually everyone has grown accustomed to just clicking through such warning dialogs.[...]

Attacks based on user ignorance of anything to do with PKI or TLS will apply regardless of “high assurance” certificates or not. What really matters here is whether or not browser security indicators matter to users (e.g., do users know about the security indicators provided by a browser, what the indicators mean, and what should be done in response to the indicators?).

[...]verifying that you are in fact establishing an SSL/TLS session with the proper entity.[...]

[...]countering an SSL/TLS MITM attack.[...]

This is an active research area. Petnames have been proposed, which I like (think PGP web of trust in some form). This has similarities to the SSH-type trust model, which has also been proposed and which I also like. In recent minutes to an IETF-PKIX meeting, the Opera people were looking at “extended validation” certificates. There has been all sorts of talk, pros and cons, about “high-assurance” certificates.

In this regard, while I like the idea of bookmarking a web site and its certificate(s), how exactly to inform a user that a certificate is changed, and establishing what actions a user should take in such a case, is the hard part. Every model I envision reduces to checking the digital certificates when the certificate presented is different from the one that is bookmarked, and then all the same problems come back into play - you might as well have just bookmarked the web site and left out the certificate.

Which leads me to what I have quoted a few times from this post.

Bookmark web sites that you visit, especially where you conduct transactions like buying stuff, and then return to those sites only through your bookmarks (this is like what we do with server public keys in SSH). Now, when you receive that email, instant message, or embedded link in some rogue web site purporting to be from, or purporting to point you to, Paypal and you really do feel it necessary to log into Paypal in response, don’t follow any of the links provided - instead, use your bookmark for the Paypal web site. It doesn’t solve all these problems, but it helps quite a bit.

Combine that with a broader version of something like PwdHash or, better yet, throw in widespread deployment of TLS with pre-shared keys (PSKs) (RFC 4279), and there you go.

-

I noticed this paper.

We develop and evaluate a system we call Loud-and-Clear (L&C) which places very little demand on the human user. L&C involves the use of a text-to-speech (TTS) engine for vocalizing a robust-sounding and syntactically-correct (English-like) sentence derived from the hash of a device’s public key. By coupling vocalization on one device with the display of the same information on another device, we demonstrate that L&C is suitable for secure device pairing (e.g., key exchange) and similar tasks.

This reminds me of one of the ways people (including myself) perform remote, (somewhat) out of band verification of each other’s OpenPGP public keys during an initial exchange of those keys over, say, the Internet.

The general idea is that I send my OpenPGP public key to my buddy via, say, email. Now, my buddy has no way of knowing whether the key received via email is actually from me - for example, someone else could have sent them a OpenPGP public key and claimed it was from me, or someone could be sitting in between us and replaced my key with their own. So, I call my buddy (or vice versa) and read off the key’s fingerprint while my buddy verifies that the key received has that fingerprint, usually by visually matching what I am reading off.

Of course, we don’t use Mad Libs, but some OpenPGP applications do translate the fingerprint into a string of words, instead of just displaying it in raw hex. Whatever floats your boat.