Some notes – ff3, gpg, iptables, dhclient, printk, djbdns

March 11th, 2009

I have been lax on my note taking, but here are a few notes and tips that have come up over the last few months. (I think I did better with formatting this time, after some mockery for this post.)

  1. Firefox 3 is configured to download a BBC news feed (Bookmarks->Bookmarks Toolbar->Latest Headlines) by default. You can just remove the offending bookmark to do away with this behavior.
  2. The way import and export of OpenPGP keys with multiple sub-keys works in GnuPG (1.4.9) is a bit counter-intuitive to me. If you generate a new sub-key pair for an OpenPGP key in a GnuPG key ring and then export the public and secret components of that OpenPGP key, and then try importing that OpenPGP key into another GnuPG key ring that already has an older version of that OpenPGP key (i.e., the version prior to the addition of a new sub-key pair), the already existing and unchanged components of the OpenPGP key will remain unchanged (as expected) but only the public component of the new sub-key will be imported (as unexpected). In order to get the complete OpenPGP key imported, you will first have to delete the public and private components of the key from the key ring into which you want to merge this updated key (back up the key ring first), and then import the key. Also, you may want to (re)set the trust of the key after doing so.
  3. On FreeBSD, “pkg_deinstall” is quite helpful in pruning your installed ports tree, especially for the clean up of dependencies for ports that are being, or have been, removed – in particular the “-r” and “-R” options, which have the same meaning as with “pkg_info” (in reverse) or “portupgrade”. Also, I find running “portupgrade -an” useful to see what will be upgraded prior to actually doing the upgrades.
  4. Using a box running Ubuntu (8.10) server (without X and its children) with iptables for IP forwarding with NAT is quite easy. An extremely helpful concept to keep in mind is that, within the “filter” table (the default table), the “INPUT” and “OUTPUT” chains are for packets terminating or originating at the box respectively, while the “FORWARD” chain is for packets flowing through the box. So, say you have a box already configured with “filter” table “INPUT” and “OUTPUT” rules that make you comfortable; adding “filter” table “FORWARD” rules does not generally require modification to these existing “filter” table rules, although you may want/need to tweak things a bit for your new setup. However, you do need to remember to consider which “INPUT” and “OUTPUT” rules you also want applied to “FORWARD” rules and set things up accordingly. Also, the “nat” table is independent of the “filter” table and its rules are used to mangle packets rather than filter them.

    With that said, this HOWTO contains a helpful example set of rules for IP forwarding with NAT using iptables.

  5. On Ubuntu (8.10) server (without X and its children), dhclient has the ability to run scripts before (“/etc/dhcp3/dhclient-enter-hooks.d/”) or after (“/etc/dhcp3/dhclient-exit-hooks.d/”) it configures interfaces from the information gathered through DHCP, a nice supplement to the good old “/etc/network/pre-if-up.d/” and “/etc/network/if-up.d/”, and “/etc/network/pre-if-down.d/” and “/etc/network/if-down.d/”. So, for example, you can use this to reload your iptables rules, if, say, you have rules tied to information that was configured via DHCP. Or, to invoke ddclient, if you have a public IP address assigned via DHCP and use a dynamic DNS service.

    E.g. a very generic ddclient script,

    sudo vi /etc/dhcp3/dhclient-exit-hooks.d/ddclient
    

    And add something like the following to it,

    (Note: This is an illustration and has not been tried by me exactly as it is here. Actually, ddclient seems like a rather poor example for this, but oh well.)

    # Note: only really makes a slight bit of sense if an interface
    # is configured with a DHCP assigned public IP address, and that
    # is the interface used by ddclient.
    
    DDCLIENT_CONF=/etc/ddclient.conf
    DDCLIENT_CACHE=/var/cache/ddclient/ddclient.cache
    DDCLIENT_USER=ddclient
    
    rerun_ddclient() {
            [ -e /usr/sbin/ddclient ] || return
    
            [ -e $DDCLIENT_CONF ] || return
    
    # Note: ddclient performs this sort of check itself as well.
            if [ -e $DDCLIENT_CACHE ] && [ -n "$old_ip_address" -a "$old_ip_address" = "$new_ip_address" ]; then
                    return
            fi
    
    # (I know, not /bin/sh -e, but habit.)
    
    # Runs ddclient as user other than root, but you must have
    # configured such a user and set ddclient up to work with them.
    #       /usr/bin/sudo -u $DDCLIENT_USER /usr/sbin/ddclient >/dev/null 2>&1 || true
    
    # ddclient is run as root here.
            /usr/sbin/ddclient >/dev/null 2>&1 || true
    }
    
    ddclient_whattodo() {
            case $reason in
                    BOUND|RENEW|REBIND|REBOOT)
                            rerun_ddclient
                            ;;
                    EXPIRE|FAIL|RELEASE|STOP)
                            ;;
                    *)
                            ;;
            esac
    }
    
    ddclient_whattodo
    

    The manpage for “dhclient-script” details the various “$reason”’s for why dhclient-script is being invoked as well as the other variables available, such as “$new_ip_address” and “$old_ip_address”, that can be used to determine the actions you want your scripts to take. Also, “/sbin/dhclient-script” uses “run-parts –list” to generate the list of scripts to be invoked, and this list is alphabetical. So, if your scripts need to be invoked in a certain order, keep that in mind.

    Note: While outside the scope being discussed here, if you are using the Gnome (2.24) NetworkManager to manage your network interfaces, then dhclient is invoked with the “-sf” option to override the use of the standard “/sbin/dhclient-script” with “/usr/lib/NetworkManager/nm-dhcp-client.action”, which does not run the scripts in “/etc/dhcp3/dhclient-enter-hooks.d/” or “/etc/dhcp3/dhclient-exit-hooks.d/”. You may still make due with using the good old “/etc/network/pre-if-up.d/” and “/etc/network/if-up.d/”, and “/etc/network/pre-if-down.d/” and “/etc/network/if-down.d/”, which have generally been fine for my use cases. Or, perhaps you could probably write a script to monitor D-Bus for a “PropertiesChanged” signal from “org.freedesktop.NetworkManager.DHCP4Config” and then check if a new IP has been assigned. Or, maybe there is a more standard plugin mechanism. Who knows, I haven’t played with it.

  6. On Ubuntu (8.10) server (without X and its children), dhclient has this habit of overwriting “resolv.conf” by default. This is useful in many cases, but, if not, you can override it creating a custom “make_resolv_conf()” function in “/etc/dhcp3/dhclient-enter-hooks.d”.

    E.g.,

    sudo vi /etc/dhcp3/dhclient-enter-hooks.d/donotmodifyresolvconf
    

    And add something like the following to it,

    make_resolv_conf() {
            return
    }
    

    Note: While outside the scope being discussed here, if you are using the Gnome (2.24) NetworkManager to manage your network interfaces, then, as noted previously, dhclient is invoked with the “-sf” option to override the use of the standard “/sbin/dhclient-script”. So, to configure this sort of DHCP settings for a particular interface in Gnome using the NetworkManager, you could instead go to Main Menu->System->Preferences->Network Configuration, select the interface you want to configure and click “Edit”, go to the “IPv4 Settings” tab, and select “Automatic (DHCP) addresses only” along with filling in the static DNS information. Also, see this for underlying details of the settings available.

  7. The Linux kernel “printk” setting determines what kernel messages will be displayed on the console. On a stock Ubuntu (8.10) server install (without X and its children, and using the stock syslog), one can use “sysctl kernel.printk” or “cat /proc/sys/kernel/printk” to display this setting, which will look something like “4 4 1 7″. What these numbers mean is as follows,

    include/linux/kernel.h

    #define	KERN_EMERG	"<0>"	/* system is unusable			*/
    #define	KERN_ALERT	"<1>"	/* action must be taken immediately	*/
    #define	KERN_CRIT	"<2>"	/* critical conditions			*/
    #define	KERN_ERR	"<3>"	/* error conditions			*/
    #define	KERN_WARNING	"<4>"	/* warning conditions			*/
    #define	KERN_NOTICE	"<5>"	/* normal but significant condition	*/
    #define	KERN_INFO	"<6>"	/* informational			*/
    #define	KERN_DEBUG	"<7>"	/* debug-level messages			*/
    

    kernel/printk.c

    /* printk's without a loglevel use this.. */
    #define DEFAULT_MESSAGE_LOGLEVEL 4 /* KERN_WARNING */
    
    /* We show everything that is MORE important than this.. */
    #define MINIMUM_CONSOLE_LOGLEVEL 1 /* Minimum loglevel we let people use */
    #define DEFAULT_CONSOLE_LOGLEVEL 7 /* anything MORE serious than KERN_DEBUG */
    
    int console_printk[4] = {
    	DEFAULT_CONSOLE_LOGLEVEL,	/* console_loglevel */
    	DEFAULT_MESSAGE_LOGLEVEL,	/* default_message_loglevel */
    	MINIMUM_CONSOLE_LOGLEVEL,	/* minimum_console_loglevel */
    	DEFAULT_CONSOLE_LOGLEVEL,	/* default_console_loglevel */
    };
    

    So, at the time of this writing, we see that “kernel.printk=”7 4 1 7″” is the 2.6 Linux kernel default; on Ubuntu (8.10), “kernel.printk” is set to “4 4 1 7″ by default (see “/etc/sysctl.d/10-console-messages.conf”). Let’s say I want “kernel.printk” to be set to “6 4 1 7″.

    There are lots of ways to accomplish this. Besides “klogd -c” or the old “echo /proc/sys/kernel/printk”, sysctl can be used to set “/proc/sys” parameters at runtime (e.g., “sudo sysctl kernel.printk=”6 4 1 7″”) on Ubuntu (8.10), but such changes are lost at reboot and let’s say I want this setting applied at each boot. Ordinarily, if you want certain “/proc/sys” parameters to be automatically set at boot and you are not doing so anywhere else (e.g., in some other rc.d script), you either add files in “/etc/sysctl.d” containing the parameter settings, or you add/modify parameters in “/etc/sysctl.conf”.

    Now, on Ubuntu (8.10), the settings in “/etc/sysctl.d/*.conf” are applied after those in “/etc/sysctl.conf”, which means “/etc/sysctl.d/*.conf” settings will override “/etc/sysctl.conf” settings. Since Ubuntu (8.10) uses “/etc/sysctl.d/10-console-messages.conf” to set “kernel.printk=”4 4 1 7″”, I need to either edit that conf or add my own that is set after that one. To do things “properly,” I should go with the latter, by, say, copying “10-console-messages.conf” to “60-console-messages.conf” (60 is the standard prefix for user customizations) and then editing “60-messages-console.conf” to contain “kernel.printk=”6 4 1 7″”.

    I guess, rather than overriding “printk” defaults, I could instead configure the stock syslog by, say, modifying its default configuration file (“/etc/syslog.conf”) to display log entries to the console, and this could be used to cover both system logs and kernel messages. Leaving alone the Ubuntu “kernel.printk” default of “4 4 1 7″, by adding a line like “kern.info;kern.!err /dev/console”, kernel messages of priority “info” (6) or more critical should be displayed to the console (the “kern.!err” is there because we are already displaying “err” and higher priority messages by virtue of the Ubuntu default “kernel.printk” configuration). Going broader than just the kernel, a line like “*.info /dev/console” would cover all system log entries of priority “info” or more critical. Generally though, if I want kernel messages dumped to the console, I work within the parameters of the kernel itself, namely “kernel.printk”.

    Coming back to iptables, the “log-level” option of iptables “LOG” rules can be used to tweak what will hit the console. Now, unless iptables is told to use a specific loglevel, the system default seems to be used. So, with the “4 4 1 7″ setting used by default on Ubuntu (8.10), iptables “LOG” rules without the “–log-level” option will not result in console messages, and only those “LOG” rules with a “–log-level err” or more serious will hit the console. With the “7 4 1 7″ kernel default, iptables “LOG rules” without the “–log-level” option will result in console messages, and only those “LOG” rules with a “–log-level debug” will not hit the console.

    Tying this into syslog a bit, if, say, there are quite a bit of kernel log entries generated by iptables and whittling back the “LOG” rules is not satisfactory, syslog rules could be used to split the kernel logs into pieces to help with manual review and remove redundant logging. So, using the “–log-level debug” in “LOG” rules and adding an entry like “kern.=debug -/var/log/kern.debug” in “/etc/syslog.conf” would place all iptables log entries (and other kernel messages with a priority of “debug”) into “/var/log/kern.debug”, while the default “/var/log/kern.log” would still contain all kernel messages (and the default “/var/log/debug” would still contain most debug log entries and the default “var/log/syslog” would still contain most log entries). Or, you could split the kernel logs up into, say, “kern.debug”, “kern.info;kern.!err”, and “kern.err”, and then use “–log-level” rules to determine to which kernel log the iptables “LOG” rules are logged. Combining such a split of the kernel logs with removing kernel messages from the default logs could help reduce redundancy as well, although care should be taken because sometimes applications depend on the default logs being, well, set to the defaults. (On a side note, if you are doing more than just simple basics with syslog, it may be time to consider replacements like rsyslog and syslog-ng.)

    (Whew, I hope I typed all that correctly.)

  8. Having had to rebuild djbdns a bit recently and remembering this post, I updated “/etc/event.d/svscan” to handle a system shutdown a bit friendlier.

    E.g.,

    sudo vi /etc/event.d/svscan
    

    And add something like the following to it,

    (Note: The following is an example and has not been tried by me exactly as it is here. FYI, “svscanboot” might be located somewhere other than “/command”.)

    # svscan - daemontools -- http://www.froyn.net/blosxom/blosxom.cgi/2007/1/12
    #
    
    # This service maintains an svscan process from the point the system is
    # started until it is shut down again.
    
    start on runlevel 2
    start on runlevel 3
    start on runlevel 4
    start on runlevel 5
    
    stop on runlevel 0
    stop on runlevel 1
    stop on runlevel 6
    
    exec /command/svscanboot
    respawn
    

Quickies – zero, conficker, https, djbdns, fashion

February 27th, 2009

This month has certainly been interesting.

A couple of zero days in widely deployed software were discovered by virtue of active exploitation out there in the world…

An Adobe Acrobat and Reader zero day [demo exploits], with an official patch expected next month (there is an unofficial patch).

A critical vulnerability has been identified in Adobe Reader 9 and Acrobat 9 and earlier versions. This vulnerability would cause the application to crash and could potentially allow an attacker to take control of the affected system. There are reports that this issue is being exploited.

Adobe is planning to release updates to Adobe Reader and Acrobat to resolve the relevant security issue. Adobe expects to make available an update for Adobe Reader 9 and Acrobat 9 by March 11th, 2009. Adobe is planning to make updates for Adobe Reader 7 and 8, and Acrobat 7 and 8, available by March 18th.[...]

Update: Adobe has released the security updates for Acrobat and Acrobat Reader 9.

A potential Microsoft Excel zero day, with more information to be determined.

Microsoft is investigating new public reports of a vulnerability in Microsoft Office Excel that could allow remote code execution if a user opens a specially crafted Excel file. At this time, we are aware only of limited and targeted attacks that attempt to use this vulnerability.

As always, exploiting vulnerabilities for which patches are available is working quite nicely too – just look at Conficker having a ball.

Why Conficker has been able to proliferate so widely may be an interesting testament to the stubbornness of some PC users to avoid staying current with the latest Microsoft security patches  [2].  Some reports, such as the case of the Conficker outbreak within Sheffield Hospital’s operating ward, suggest that even security-conscious environments may elect to forgo automated software patching, choosing to trade off vulnerability exposure for some perceived notion of platform stability [8].   On the other hand, the density of where the vast bulk of Conficker victims are concentrated may also suggest other reasons, such as the wide use of unregistered (pirated) Windows releases, which Microsoft does not patch [9].  

Browser usability with https continues getting hammered as well.

This tool provides a demonstration of the HTTPS stripping attacks that I presented at Black Hat DC 2009. It will transparently hijack HTTP traffic on a network, watch for HTTPS links and redirects, then map those links into either look-alike HTTP links or homograph-similar HTTPS links. It also supports modes for supplying a favicon which looks like a lock icon, selective logging, and session denial. For more information on the attack, see the video from the presentation below.

The djbdns package has come under fire, of particular note.

Summary: Weaknesses in dnscache’s outgoing query management and caching policies allow an attacker to poison arbitrary DNS records in far less time than previously believed possible.
Versions Effected: All current versions of djbdns (< =1.05)

(And, now I know about zinq.)

And, to end on a lively, off-topic note, fall fashion in New York is usually a favorite of mine, and the Fall 2009 season combined that general preference with up my alley trends (already visible on the streets of New York) – comforting protective and edgier futuristic clothing, dark somber and rich powerful colors (e.g., royal blue, plum purple, forest green), playing with construction and textures (e.g., velvet, tweed, leather, satin), asymmetrical geometrical strong-shouldered architectural designs. Because of these trends, many shows had at least a few pieces that I loved, making for my much wider appreciation of the designs of a variety of designers this season. Some of my favs…

  • Yet again, Proenza Schouler – This collection veered slightly softer and perhaps nodded to their earlier days, yet still maintained the edge and architecture I have come to love. In a season where those I thought would shine seemed to go astray, these guys hit the mark.
  • Rodarte – This collection had singular point of view, with the same silhouette and structure throughout; however, the play with construction, textures, and even a pop of color kept it so interesting that I could not wait to see what would come next.
  • Ralph Lauren – This collection was like walking out into a clean, clear, crisp fall day and inhaling deeply. I said it over and over – it feels like a breath of fresh air. The simplicity, elegance, and beauty of the clothing was remarkable.

Of course, given the trends and my high expectations, I must note there were a number of train wrecks out there too. The two main categories I saw: 1) designs that looked plain silly, gaudy, and/or obnoxious, a way too literal translation of the 1980s; and 2) designs that looked stiff, heavy, and/or just plain burdensome, too much like wearing actual medieval armor, scratchy carpeting, or sound absorbing curtains.

Games and adaptions

February 12th, 2009

This post is big, too big. Alas, dear reader, you must serve as editor.

-

In a previous post, I wrote,

This suggested to me that players, people, will adapt to a structure over time, and, as I quite often see out there in the world, will likely learn ways to game the system. This adaptation to, or gaming of, the system can lead to new or unintended outcomes, perhaps beneficial, perhaps otherwise. In response, the structure will be modified to incorporate these behaviors and outcomes, perhaps encouraging them, perhaps counteracting them. And so on.

(I must say that John Barrow’s “The Artful Universe” just sprang to mind, a book that ventures an explanation of why things are the way they are.)

Thinking of gaming the system brings security to mind. Security generally seems to follow this pattern of tweaks – attacks get better, and defenses are modified accordingly. However, when a situation of radical change occurs, the instability that results can make security objectives quite difficult to meet, even if defined objectives exist. After all, locking down a system generally requires that the system have some stability and structure. Security itself is structure, and instability breaks down structure. So, radical change can require a shift from tweaks to a wider (re)building of a security structure as areas of this new system solidify.

Ok, this seems obvious. But, why not look at some examples?

Since the economy is on people’s minds these days, I thought these excerpts from Michael Lewis’ “Liar’s Poker” about Wall Street in the 1980’s would serve as the first, and perhaps best, example.

[...]At a rare Sunday press conference, on October 6, 1979, Paul Volcker announced that the money supply would cease to fluctuate with the business cycle; money supply would be fixed, and interest rates would float. The event, I think, marks the beginning of the golden age of the bond man. [...] Bond prices move inversely, lockstep, to rates of interest. Allowing interest rates to swing wildly meant allowing bond prices to swing wildly. Before Volcker’s speech, bonds had been conservative investments, into which investors put their savings when they didn’t fancy a gamble in the stock market. After Volcker’s speech, bonds became objects of speculation, a means of creating wealth rather than merely storing it. Overnight the bond market was transformed from a backwater into a casino.[...]

The mortgage trading desk evolved from corner shop to supermarket. By increasing the number of products, they increased the number of shoppers. The biggest shoppers, the thrifts [savings and loans], often had a very particular need. They wanted to grow beyond the limits imposed by the Federal Home Loan Bank Board in Washington. It was a constant struggle to stay one step ahead of thrift regulators in Washington. Many “new products” invented by Salomon Brothers were outside the rules of the regulatory game; they were not required to be listed on thrift balance sheets and therefore offered a way for thrifts to grow. In some cases, the sole virtue of a new product was its classification as “off-balance sheet.”

[...]Demand now exceeded natural supply. Huge pools of funds across America were dedicated to the unbridled pursuit of risk. Milken and his Drexel colleagues fell upon the solution: They’d use junk bonds to finance raids on undervalued corporations, by simply pledging the assets of the corporations as collateral to the junk bond buyers. (The mechanics are identical to the purchase of a house, when the property is pledged against a mortgage.) A take-over of a large corporation could generate billions of dollars’ worth of junk bonds, for not only would new junk be issued, but the increased leverage transformed the outstanding bonds of a former blue-chip corporation to junk.[...]

Washington Irving, so many years ago, best summed up how this sort of thing ends, words to which we can all relate today.

Could this delusion always last, the life of a merchant would indeed be a golden dream; but it is as short as it is brilliant. Let but a doubt enter, and the “season of unexampled prosperity” is at end. The coinage of words is suddenly curtailed; the promissory capital begins to vanish into smoke; a panic succeeds, and the whole superstructure, built upon credit and reared by speculation, crumbles to the ground, leaving scarce a wreck behind:

“It is such stuff as dreams are made of.”

Which takes me on a bit of a diversion…

When people discuss the economic situation of today, I sometimes notice a common mistake, a confusion of the representation (e.g., money) with the reality (e.g., productivity). We as people are great at building representations of the world to suit our purposes. For example, we build a visual representation of the world using our eyes and brain in order to assist with our navigation of this world. That visual representation is not reality, it is a representation of a small slice of reality, that slice useful to our moving around in the world, generated by our brains from inputs gathered by our eyes. However, if that representation becomes very distorted, if we can no longer make out objects blocking our path, we start to bump into things, we fall down, we hurt ourselves. Our distorted visual representation no longer adequately reflects reality for the purposes to which that representation was to be used.

Perhaps a more relevant example, say you have a map of your town depicting all the roads in your town. That map is one representation of your town, and it can be used to assist in the navigation of your town by road. However, you would never confuse tracing your finger along some path on that map with actually walking the streets of your town (i.e., “the map is not the territory“). Drawing a new road on that map does not magically create a new road in your town. And, if that map depicts roads not actually in your town, its usefulness for navigation is limited – you might just throw it away.

Coming back to the economic news of today, one way to think of money is as a representation of productivity. We created this representation to facilitate trade, savings, and investment, but, in order to be useful for these purposes, the representation must reflect the reality of productivity, much as our visual representation of the world must reflect the physical reality around us to facilitate our navigation. Money is not productivity any more than a map of your town is your town.

Now, people are good at gaming the system, and the system of money has been no exception here – people have learned how to game the system of money. Money was much easier to manipulate than the productivity it was supposed to represent, and gradually this property became heavily abused, rather than just used, by people. At some point, people lost sight of the reality for the representation, and the accumulation and growth of the representation became a goal unto itself. Productivity was left in the dust, like drawing a million roads on the map of your town but never building any of them. The representation was distorted away from the reality, and that distortion has now become so great as to severely damage the usefulness of the representation for its purposes.

(When you hear discussions of how to fix the system, what is being debated is how to remove the distortion and limit it in the future. Assuming the current system is to be retained, there seem to be two primary ways to remove the extreme amount of distortion from what I gather from others: 1) devalue the money, thus reducing the debt load denominated in that money to a level commensurate with realistic future productivity estimates, or 2) default on debt, thus reducing the debt load to a level commensurate with realistic future productivity estimates. (I am ignoring those caught up only in the representation and missing the reality, but decisions could certainly be made to go further in this direction as well.) Whatever happens, the result is, and will be, painful for many, and so the other topic of conversation is how best to limit the hurt.)

All of this brought to mind an interesting point with regards to design versus implementation flaws in light of representations and their purposes:

  1. A design flaw causes a system to misrepresent reality such that the objectives of that system are broken for all implementations of that design.
  2. An implementation flaw causes a system to misrepresent reality such that the objectives of the system are broken due to a mistake in implementing the design rather than a mistake in the design itself (and so only the mistaken implementation is broken).

Also, as I journey down this path, I am reminded that exploitation of the human factor has been a recurring topic in this blog. Attacks of this sort often boil down to taking advantage of a vulnerability created by a misrepresentation of people in a system. Which brings to mind three concepts utilized in systems and their relation to the people factor:

  1. Regulate. This attempts to restrict the human factor by trying to limit what people can do.
  2. Audit. This attempts to learn about the human factor by providing the ability to know what people do.
  3. Educate. This attempts to adapt the human factor by teaching the reality to comply with the representation.

Much like a self-help book, these bullet points make the world seem way too simple. For example, there may be a complex balancing act, overlap, and feedback between these three concepts, as well as, between these three, risk, productivity, and resources. Nevertheless, the abstraction seemed useful to my purposes. ;)

Ok, enough of this branch, let me get back on track. What follows are some examples of games and adaptations taken from this blog’s history.

Evolution seems the logical place to start in this travel through some prior posts, which leads us to an example found here.

Anyway, ignoring the multitudes of other factors around this sort of evolutionary understanding, it can be said that at least some part of our brains evolution seems like the result of a bit of an arms race. Our brains evolving more and more powerful capabilities for impressing potential mates (offensive capabilities) while at the same time evolving more and more powerful capabilities for selecting from potential mates (defensive capabilities). It could be that we are a product of “our own” attempts to secure reproduction. Cool beans.

(I can’t help but think of Geoffrey Miller’s “The Mating Mind”.)

This brings to mind some thoughts from an old ramble,

Moving on from just beauty, marketing and sales are about trying to influence people to spend their limited resources (e.g., time, money) on certain products (e.g., goods, services) over other products. This done is [yes, a typo in the original] through many means, both overt and covert. It preys upon our base programming and our learned experience – things like social value, liking someone, or even just wanting to seem consistent – to get us to do things the marketing and sales people want. (Remember this?) Beauty helps with things like being liked and social value. It also helps make objects and other people more desirable. Think of that attractive model sitting on that car for sale – regardless of how blatant the use of the model is, your brain makes associations between that model and that car. And, as noted above, I can think of the increased attention I get when I am out with beautiful people – my social value is increased just by association.

(Robert Cialdini’s “Influence” is right up this alley.)

And its follow-up,

The thing is, all our base programming and all our experience can be used against us. From the power of beauty to inaccurate perceptions of risk, it could be that security mechanisms fail to meet their objectives because, well, real people are involved. When security does not hit upon how real people act out there in the real world, it seems to miss a big chunk of risk.

Which leads us to discussions of ID (age) checks.

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 [yes, another typo] 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%.

The crypto world tends to be conservative, but it moves nonetheless.

RSA has come up here.

Also via Metzger’s cryptography mailing list, five years to the month after Lucky Green spoke out and said no more to 1024 bit RSA keys, the gap continues to close on 1024 bit RSA keys.

As has password hashing.

Even with salts, the traditional Unix crypt function is quite dated and may not be a good choice for generating password hashes. The tiny salts, short password length, optimizations, current processing speeds, etc. all combine to make crypt function generated password hashes quite susceptible to password cracking efforts. The two common alternatives are the MD5 crypt function, which uses the MD5 hash algorithm as its underlying crypto primitive and incorporates a salt, and the blowfish crypt function, which uses the blowfish encryption algorithm with modified key schedule as its underlying primitive and incorporates both a salt and an interation count. The blowfish crypt function is considered to be the latest and greatest crypt function that is widely deployed.

As is the search for a new SHA.

Backing out to a common IT task, a recent post illustrates the vulnerability followed by patch stream many of us know all too well.

USN.
[...]
FreeBSD VuXML.
[...]
FreeBSD Security Advisories.

Like patching vulnerabilities (and segueing back to people), when we recognize the games of others, we can adapt to them.

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.

(While I note Cialdini there, Paul Eckman’s “Emotions Revealed” also seems relevant.)

And now, dear reader, as you are likely reaching the end of your rope, we shall finally finalize this regurgitation with the finale of a prior set of rambles for our finish.

First off, we need a threat model. We need to figure out what we want to protect, its value, the potential attacks, the likelihood of those attacks, and the potential damage of those attacks. Determine the risks, and then mitigate them. Very important here is figuring out who needs to be held responsible for what mitigations and countermeasures. And, this threat model has to be reviewed periodically to keep it up to date. The assets that need to be protected change, the way business is done changes, the risks change, the mitigations change. Security is not static.

With that (and building that is certainly not trivial), we have these people, you, me, our parents, that are part of this threat model. They pose risks, and they help to mitigate risks. We need to minimize the former and maximize the latter. To do this right, I think we need people to feel responsible for security. To build this sense of responsibility, we need these security responsibilities audited and we need effective training to convey and reinforce these responsibilities – the combination of these two may be a linchpin to people security.

So, we talk to people about our threat model. Not only do we teach it, but we get feedback on it. And, we make sure everyone understands that threat model, and their place in it. To do this, we bring vivid examples from security audits into our security education, which help to build security training programs that provide exactly that which we learn the most from, experience.

FreeBSD 7.1, etc.

January 31st, 2009

Just a few notes:

  1. Upgrading to FreeBSD 7.1 stable from FreeBSD 7.0 stable went smoothly.

    Sort of standard steps…

    • vi /usr/mykernconf7 and modify to merge in 7.1 changes into my custom kernel config.

      (The generic FreeBSD kernel configuration for the i386 platform as a starting point can be found in “/usr/src/sys/i386/conf/GENERIC”.

        e.g.,

      • cp /usr/src/sys/i386/conf/GENERIC /usr/mykernconf7
      • ln -s /usr/mykernconf7 /usr/src/sys/i386/conf/mykernconf7
      • vi /usr/mykernconf7 and modify as desired)
    • vi /usr/stable-supfile and update my custom “stable-supfile” to point to “RELENG_7_1″ by changing the relevant line to “*default release=cvs tag=RELENG_7_1″

      (A sample “stable-supfile” as a starting point can be found in “/usr/share/examples/cvsup/stable-supfile”.

        e.g.,

      • cp /usr/share/examples/cvsup/stable-supfile /usr/stable-supfile
      • vi /usr/stable-supfile and modify as needed, such as setting the default release to 7.1 and setting the host to one of the FreeBSD cvs server mirrors)
    • cd /usr/src
    • cvsup -g -L 2 ../stable-supfile
    • make buildworld
    • make kernel KERNCONF=mykernconf7
    • reboot (to single user mode)
    • cd /usr/src
    • mergemaster -p
    • make installworld
    • mergemaster

      I found there was a massive version increment of the contents in “/etc” from 7.0, so there was a lot to go through. I had a few mods to configuration and script files that needed merging, but, for the majority, just installing the new version was fine.

    • reboot
  2. With the release of FreeBSD 7.1, the FreeBSD ports have undergone a huge burst of activity. Over the course of the last month, perl, X, and Gnome have all been upgraded.

    The first step is always the same here, updating the ports tree and grabbing the new index.

      e.g.,

    • cd /usr/ports
    • cvsup -g -L 2 ../ports-supfile
    • portsdb -Fu

    The second step is always the same here too, examining “/usr/ports/UPDATING” to see if there were any special instructions relevant to upgrading my installed ports, and additionally, browsing “/usr/ports/MOVED” to see what ports have been (re)moved.

    Ok, so there have a number of instructions that applied to my installed ports over the last month or so, including those for perl, X server, and Gnome. I updated multiple times and so upgraded many of these components at different intervals, which kept the mixing and matching of these instructions somewhat minimal. (On the flip side, there was a bunch of redundant (re)building of my ports.)

    Of the big boys (i.e., perl, X, and Gnome)…

    My first upgrade was of perl from 5.8.8 to 5.8.9, and I did this by itself, as the upgrade involved manually using a script and its guidance after installation of the upgrade perl, as per the 20090113 instructions in “/usr/ports/UPDATING” for perl5.8. (If perl troubles crop up after using this script, rebuilding the perl dependents may be best.)

    Next came the upgrade of Gnome from 2.22 to 2.24 (and all other updated ports at the time), which went smoothly enough, according to the 20090114 instructions in “/usr/ports/UPDATING” for GNOME and GTK+. (During this upgrade, I discovered some issues with my perl upgrade, so I ended up just rebuilding my perl dependents, but that was not the fault of the GNOME update.)

    A few days later followed the upgrade of libxcb by itself along with the rebuilding of all its dependents according to the “/usr/ports/UPDATING” 20090123 instructions for libxcb.

    Then, the upgrade of X (and all other updated ports at the time). There were issues here and there after this upgrade, but these seem to have been mostly resolved by subsequent updates, as the port maintainers have been tweaking things.

    As mention already, these steps were mostly incremental for me, happening in two primary bursts. If you are upgrading all of that and more at once, it might be easier to just rebuild all ports while taking “/usr/ports/UPDATING” instructions into account.

  3. Tor stable (and development) has been updated to fix a remotely inducible heap corruption issue. Details forthcoming.

    This update also fixes an important security-related bug reported by Ilja van Sprundel. You should upgrade. (We’ll send out more details about the bug once people have had some time to upgrade.)

    Changes in version 0.2.0.33 – 2009-01-21
    o Security fixes:
    – Fix a heap-corruption bug that may be remotely triggerable on some platforms. Reported by Ilja van Sprundel.

  4. Truecrypt 6.1a has been available for over a month. The 6.1 changes include support of tokens and smart cards, and trickery to get passed, say, USA customs.
  5. Xen and Ubuntu have gone their separate ways.

PEoD

January 30th, 2009

For a while there, it was cold in NY, seriously cold. I mean, teens F day and touching upon single digits F night with wind chills that frighten small children cold. Now we are seeing the 30’s F again. Summer.

-

So, I was reading a book from back in the early 1990’s, titled “The Political Economy of Defense” and edited by Andrew Ross, that I picked up during one of my explorations of a used bookstore. The book was more geared towards a discussion of potential research topics rather than actual research, but it did leave me with some scattered thoughts.

Update: My first “controversial” post in a while has left me talking about topics this weekend that I care little to discuss with what little I know. I now regret items 3 and 4 in the bullet points below, as my attempt to at least have a couple of bullet points more in line with the book led me down a foolish path. That said, I added one minor update to item 4 below, and that will be the extent of this post’s growth. (Ok, time to enjoy Super Bowl Sunday!)

Note: As fair warning, this post is a total ramble. And, politics is part of the topic by definition, but I endeavor to keep it politically indifferent. You may want to skip it.

This first half will be generic rambling derived from some of the books content taken mostly way out of context (I guess just wanted to jot down some thoughts on, say, gaming the system).

  1. Structure influences behavior and outcomes, and vice versa.

    An example, players in a market having an oligopolistic structure tend to end up exhibiting a specific set of behaviors, and one study in the book examined the international arms market up through the 1980’s as an oligopoly. It found that while this market had some oligopolistic behaviors, it lacked others, and, overall, the structure was shifting further away from an oligopolistic market to a competitive market. Moises Naim’s “Illicit” has a description of just how far that shift has gone today.

    This suggested to me that players, people, will adapt to a structure over time, and, as I quite often see out there in the world, will likely learn ways to game the system. This adaptation to, or gaming of, the system can lead to new or unintended outcomes, perhaps beneficial, perhaps otherwise. In response, the structure will be modified to incorporate these behaviors and outcomes, perhaps encouraging them, perhaps counteracting them. And so on.

  2. Radical change can cause instability.

    An example, consider “third world” countries adopting advanced industrial country technology as discussed in the book. A major problem here can be that “third world” countries typically have a labor surplus, while advanced industrial nation technology favors less labor-intensive production. Additionally, the technical skills required to use such technology tend to be possessed by a very small portion of the labor supply in “third world” countries. So, making a leap to these technologies can facilitate mass unemployment, which can lead to, say, political instability.

    Of course, this brought to mind creative destruction and entrenched players stifling innovation, but it also served as a reminder that where we are today is built upon where we were yesterday. There is a progression that provides time for adjustment to the new. (Certain potential future advances are labeled “event horizons” precisely because they are considered to involve such radical change that all the rules go out the window.)

    Peter Turchin’s “War and Peace and War” popped into my head too, in which he examines the cycles within cycles that have made for a perpetual cycle throughout world history of conflict and instability leading to peace and stability leading to conflict and instability. The general idea is that there is a coming together phase and a falling apart phase in the life cycle of empires. Within these phases, there are various cycles, which first build the propensity for collective action, and then break down the ability for collective action. And, this often seems to start at a fault line between sets of people that differ in easily identifiable (to them) ways, where by conflict between these sets of people builds internal cohesion and equality within the sets. Once this us and them conflict is resolved and the threat mitigated, prosperity generally kicks in. Over time, prosperity brings about population growth and pushes resources (e.g., food) and grows inequality, and this breaks down the internal unity and leads to internal conflict. Eventually, through cycle upon cycle, an empire is so weakened that it dissolves, often with the help of external enemies. And so on.

    However, Turchin points out the this theoretical framework may not apply to the conditions of today (e.g., food is no longer a concern in modern societies) and applauds technology, such as the Internet and, in particular, the cell phone, as breaking down hierarchy and leading to heterarchy, which changes the rules of the game. Dalton Conley’s “Elsewhere, USA” discusses some trends we see here in the, as he coins it, “neofeudal” USA, such as massive inequality coupled with a breaking down of hierarchy and the pervasiveness of ephemeral stuff for invidious (Schoeck’s “Envy” anyone?) comparison with the exception of the readily available basics, food and water.

    Anyway, coming back to the thoughts on 1, there is a sort of continuous change implied, in which the structures, behaviors, and outcomes of a system evolve over time. However, too much change too quickly can lead to instability. This seems to promote a sort of tweaking process where some stability is desired.

    Thinking of gaming the system brings security to mind. Security generally seems to follow this pattern of tweaks – attacks get better, and defenses are modified accordingly. However, when a situation of radical change occurs, the instability that results can make security objectives quite difficult to meet, even if defined objectives exist. After all, locking down a system generally requires that the system have some stability and structure. Security itself is structure, and instability breaks down structure. So, radical change can require a shift from tweaks to a wider (re)building of a security structure as areas of this new system solidify.

    This brought to mind the situation of online security in the world of the web, a world that is radically changing right here and now. The security community is scrambling to catch up, to get a foothold and (re)build structure. For example, capability systems seem to be one possible wave of this future.

    (This also reminded me of the current economic mess in the USA, where it seems that radical financial innovations (e.g., a piece of paper saying “this is an apple” held between two mirrors was somehow magically thought to be creating infinite, edible apples) combined with much (extremely leveraged) gaming of the system played a big part in the disaster that is beginning to unfold. Of course, bubbles and credit crisis are nothing new (tulip bulbs or tech, anyone?). Which, in a mindset framed by Turchin’s book, makes cycles seem to be a way of life given our current mental composition (e.g., “Choices, Values, and Frames” edited by Kahneman and Tversky, Cialdini’s “Influence”).)

  3. This second half will be more specific rambling to a couple of topics touched upon in the book.

  4. As discussed in the book, in the USA, defense spending was quite large and had little relation to economic conditions within the country. The questions of how much defense spending and how much security came down to political decision-making.

    Perhaps political decision-making is not always the most effective and efficient, but, regardless, its makes me wonder… If states must be capable of pulling together such massive amounts of resources for defense, then, other than a new hot or cold war between major players (e.g., a China-USA showdown), conflict should be quite localized and/or take the form of, say, electronic warfare, guerilla warfare, and terrorism.

    Its makes for other interesting trade-off topics too. I can see the USA as carrying a large amount of the defense costs of the whole Occident and much of the world – this gives the USA a huge degree of power in the world, but it also allows others to free ride and focus on different efforts. The opportunity cost of defense spending is something to ponder – defense research has led to technology that is adopted by the civil sector, but it is not known what the civil sector would have come up with and produced if those resources (e.g., some of the brightest out there) had not been tied up in the defense sector. And so on.

  5. As discussed in the book, there was a mild consensus that defense spending can cause short term benefits (e.g., resource utilization) to a country’s economy, but long term it tends to be detrimental (e.g., decreased savings and investment in the civil sector). These detrimental economic effects might build on each other as well.

    Now, looking around, we tend to see large territories organized into nation states, and these are generally structured such that the government is the monopoly provider of defense in these territories. My rough understanding, a la papers such as Frederic Lane’s “Economic Consequences of Organized Violence,” is that the primary point of defense being a government monopoly in, say, modern democracies is to reduce the overall burden of defense costs allowing a greater focus on other productive endeavors by everyone else (although, in the USA, the rise of the military-industrial-congressional complex, as Eisenhower coined it, might serve to counter part of this point – e.g., Osprey and Comanche). In that direction, it may be that successful nations tend to be those that find ways to reduce defense costs while maintaining appropriate levels of security and stability. These cost savings can then be rolled into the other economic growth, and so, other things being equal, become a competitive advantage out there in the world market. Defense cost savings can also be devoted to other things, like social programs, such as health care.

    Update: Due to follow-up conversation, I now feel a need to point out two things.

    First, some have thought that my views of the world have shifted radically based on what is written in this post. While my interpretations of the world shift over time and the tendency is towards moderation, I have not been reborn. I just tried to remain indifferent in the post.

    Second, my choice of Lane’s simplified view of the world was quite simple – the idea of the government as a defense service provider to its clients, particularly with those clients being the people of the nation state in a modern democracy, trivially rolled back into the general bullet point. As with most costs, people want to get the most bang for their buck – so, the less clients pay for defense services, the more resources they have for other productive efforts. And, all things being equal, this becomes a competitive advantage over others that have to spend more on defense services for a similar level of security. This translates to more investment, more innovation, more exports, and, well, more capital, resources, wealth for the defense cost savers. Other things being equal, this also gives the defense service provider itself a competitive advantage over other defense service providers. The defense service provider could advance its defense services, at the same or perhaps quite a bit less cost, especially relative to its clients’ growing resources, and maybe even throw in other value add services that benefit from economies of scale. And so on.

    For a broader investigation of empire, I already noted Peter Turchin’s “War and Peace and War.” If you just want to hear a concise rain on much of Lane’s quick parade, Charles Tilly’s “War Making and State Making as Organized Crime” might be of interest. Finally, if you want to read radical theorizing about anarcho-capitalist ways of doing things in the future that may or may not result in a defense monopoly, you could check out David Friedman’s “The Machinery of Freedom.” Or, if you just want a fun work of fiction about such a future, Neal Stephenson’s “Snow Crash” is one of my favorites, and it contains one of coolest characters ever, Raven.

    This reiterates to me in yet another fashion that security is not, well, priceless.

    Thinking on this, the Internet is a new, massive territory. As it gains in popularity and power, nation states have started to partition this territory, much like the geographic boundaries in the physical world, which contain the physical infrastructure on which the Internet is built. If the rules of the real world hold here, then defense of large Internet territories will continue to move into the government arena. Which makes me wonder, perhaps ridiculously, if, as the virtual world moves much faster than the physical world and is, by nature, highly networked and interconnected, much as the real world is more and more becoming, and is even intermingling with the real world to such an extent that some boundaries are blurring between the two, the progression of the Internet could serve as a sort of virtual model for exploring the future of defense in the real world?

All in all, not much of this post really deals with the book. Ah well, I can’t imagine many made it this far anyway. :)

More fun with MD5, etc.

December 31st, 2008

Well, a cool, successfully employed in the real world attack leveraging weaknesses in MD5 (and CAs) has been making the rounds. [via just about everyone]

Our attack takes advantage of a weakness in the MD5 cryptographic hash function that allows the construction of different messages with the same MD5 hash. This is known as an MD5 “collision”. Previous work on MD5 collisions between 2004 and 2007 showed that the use of this hash function in digital signatures can lead to theoretical attack scenarios. Our current work proves that at least one attack scenario can be exploited in practice, thus exposing the security infrastructure of the web to realistic threats.

As a result of this successfull attack, we are currently in possession of a rogue Certification Authority certificate. This certificate will be accepted as valid and trusted by all common browsers, because it appears to be signed by one of the root CAs that browsers trust by default. In turn, any website certificate signed by our rogue CA will be trusted as well. If an unsuspecting user is a victim of a man-in-the-middle attack using such a certificate, they will be assured that the connection is secure through all common security indicators: a “https://” url in the address bar, a closed padlock and messages such as “This certificate is OK” if they chose to inspect the certificate.

The team built a list of CAs that issued certificates using MD5, and, of these CAs, picked one in particular that used predictable values for fields in the certificate that were not fully under their control (the latter reminded me a bit of the DNS implementation flaw a few months back). To generate the collision, the team appears to have pushed the state of the art for chosen prefix collision attacks for MD5, although details will be published later.

The chosen-prefix collision construction method is basically described in our EuroCrypt 2007 paper [SLW]. However, some crucial improvements to this method have been developed that made the present application possible. Details of those improvements will be published in a forthcoming academic paper. The basic idea of the method is twofold. In the second part of the method differential paths are constructed that are capable of eliminating special bit differences in the IHVs with certain probabilities. This can be called a search for near collisions. In a few consecutive “near collision blocks” thus special combinations of bit differences can be eliminated. For each bit difference a fresh differential path has to be constructed, so it is crucial to have an automated way to produce differential paths.

As a result, the few remaining CAs using MD5 seem to be kicking the habit now.

Q: Does that mean VeriSign has discontinued use of MD5?
A: We have been in the process of phasing out the MD5 hashing algorithm for a long time now. MD5 is not in use in most VeriSign certificates for most applications, and until this morning our roadmap had us discontinuing the last use of MD5 in our customers’ certificates before the end of January, 2009. Today’s presentation showed how to combine MD5 collision attacks with some other clever bits of hacking to create a false certificate. We have discontinued using MD5 when we issue RapidSSL certificates, and we’ve confirmed that all other SSL Certificates we sell are not vulnerable to this attack. We’ll continue on our path to discontinue MD5 in all end entity certificates by the end of January, 2009.

Anyway, I noted the following paragraph in this summary of the attack,

The growth of trusted root CAs included in standard browsers has been an issue for a while. Every root CA is equal in the eyes of the browser, thus the end-user’s security is equivalent to the security of the weakest root CA. The default Firefox install will accept a Yahoo cert signed by “TurkTrust”, or any other of more than 100 root certs. I don’t know how good each of those companies are at securing their keys, implementing strict cert chain validation, and checking the identity of every submitter. So, it’s a good bet that putting crypto authority in the hands of that many people will result in some failures, repeatedly.

It served as a reminder that this is today’s world, [via Cryptography mailing list]

Code signed malicious code results from either malicious code being mistakenly signed, stolen private keys issued to other entities or been issued certificates from a Certification Authority (CA). The MMPC has not confirmed any cases of private keys being stolen and used on detected code, or any cases of mistaken signing by a legitimate entity, but has confirmed many cases of CAs issuing code signing certificates to malware authors. In most cases, CAs participating in the Microsoft Root Certificate Program issue code signing certificates to a software publisher who uses the certificate to sign malware. In some cases, the CA is owned and operated by the malware authors, and the first step in infection is tricking users into installing a root certificate. In most cases, CAs participating in the Microsoft Root certificate program are tricked into issuing a valid certificate to the malware author.

In the first six months of 2008, the MMPC received reports of 22M instances of distinct malware files, of which about 173,000 were distinct malware files with code signatures. Of this malware with code signatures, about 38,000 were not validly code signed, so approximately 135,000 validly signed malware files were reported to Microsoft. Approximately 0.6% of detected malware were validly code signed.

-
Unrelated, a new version of the CAVS tool has been released.

[12-24-2008] — New release of the CAVS algorithm validation testing tool to the CMT Laboratories (CAVS7.0). Version 7.0 of the CAVS tool adds testing for NIST SP 800-56A Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography and NIST SP 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.

In addition, file formating changes have been made to the CCM Decrypt-Verification Process Test.

The transition period ends March 24, 2009.
[...]
Prior to the release of CAVS7.0, the CMVP allowed vendor affirmation for SP800-56A implementations(IG1.12) and vendor affirmation for SP800-38D implementations (IG.1.13). During the transition period, the vendor has the option of either providing the vendor affirmation in FIPS140-2 IG1.12 or IG1.13 or going through the validation testing now available in CAVS7.0. The transition period for accepting vendor affirmation for SP800-56A is being determined but will exceed the 3 months specified above. Please see the CMVP Announcements for further information.

-

Have a happy new year!

Updated draft of FIPS 186-3 released for public comment

November 14th, 2008

So, the FIPS 186-3 is getting closer to finalization, and a new draft has been published for public comment.

As stated in today’s (Nov. 12, 2008) Federal Register Notice, NIST requests final comments on FIPS 186-3, the proposed revision of FIPS 186-2, the Digital Signature Standard. The draft defines methods for digital signature generation that can be used for the protection of messages, and for the verification and validation of those digital signatures using DSA, RSA and ECDSA. [...] The comment period closes on Friday, December 12, 2008.

Along with a draft of SP 800-102 being announced for public comment.

NIST requests comments on SP 800-102, Recommendation for Digital Signature Timeliness. This Recommendation provides methods for obtaining assurance about the time that a message was signed. The concepts in this Recommendation were presented in the original public comment draft of FIPS 186,3, The Digital Signature Standard. Please provide comments [...] by December 19, 2008 [...]

A summary of the changes between this draft and the earlier ones, as well as a brief summary of the changes between FIPS 186-2 between 186-3, can be found in the Federal Register notice. In the notice, the changes between drafts are covered in a comments received and NIST response format. For those that will be specifically dealing with this future standard, I found the most interesting NIST responses to be…

A.1.1.3 is intentionally different from A.1.1.1. The change in the use of the hash function (no XORing) was in response to a cryptanalytic attack that showed how to select a set of domain parameters generated in the A.1.1.1 fashion in such a way that two ‘‘messages’’ with the same DSA signature could be found. Note that A.1.1.1 still allows domain parameters generated using the older method to be verified.

The length of the larger keys has a huge impact on communications and storage requirements. The strategy of the U.S. government is to transition to elliptic curve algorithms in order to reduce the key sizes.

NIST has chosen to base the number of tests on the key sizes and provided separate requirements for each. An implementer can choose to combine the requirements into fewer categories, as long as the number of rounds for each key size are equal to or greater than the numbers provided in the FIPS.

The only other NIST document containing approved methods for random number generation is FIPS 186–2. With the approval of FIPS 186–3, those methods will no longer be approved, subject to a transition period posted by the Cryptographic Module Validation Program (CMVP).

My comments on the draft proposed back in 2006 plus feedback from readers can be found here. I was happy to see the focus refined to be solely on the digital signature algorithms, and other information migrated elsewhere. Even so, I do have a little concern about the complexity of the document – it almost feels like there is too much information and too many options to make a clear standard, but maybe not.

Update: As with RSA digital signatures, the world has been using RSA for key exchange for years, even in FIPS-validated modules. So, a draft of SP800-56B has been released for public comment.

NIST requests comments on Draft SP 800-56B, Recommendation for Pair-Wise Key Establishment Using Integer Factorization Cryptography. This Recommendation provides the specifications of asymmetric-based key agreement and key transport schemes that are based on the Rivest Shamir Adleman (RSA) algorithm.

Too quick – hash competition, petname tool, etc.

November 6th, 2008

Still here. Work. Read. Work. Read.

-

Cool, cool, cool. The deadline for the NIST hash competition submissions was Halloween 2008 (2008-10-31), and a tally of the received submissions (64!) has now been provided via the hash mailing list.

Date: Wed, 5 Nov 2008 17:02:07 -0500
From: Shu-jen Chang
To: Multiple recipients of list
Subject: Submission tally

>Do we know how many submissions were made??

We have received 64 submissions, but not all of these are “complete and proper”. As soon as we are ready to make the determination for all the submissions, we will post the first round candidates on our web site.

Thanks,
Shu-jen

Update: The list of first round candidates has now been published by NIST. Of the 64 submissions, 51 qualified for the first round!

And, a conference has been announced.

The First SHA-3 Candidate Conference will be held at K.U. Leuven, Belgium, following the 16th International Workshop on Fast Software Encryption (FSE 2009) which is scheduled for February 22-25, 2009. The purpose of the SHA-3 Conference is to allow the submitters of the first round candidates to present their algorithms, and for NIST to discuss the way forward with the competition.


Update: The conference program has been posted.

While we wait for NIST to release a list of first round candidates, there is an attempt to aggregate the known submissions here.

The SHA-3 Zoo is a collection of cryptographic hash functions (in alphabetical order) submitted to the SHA-3 contest. It’s aim is to provide an overview of design and cryptanalysis of all submissions. For a performance-related overview, see eBASH.

Somewhat related…

FIPS 180-3 has been released.

The National Institute of Standards and Technology (NIST) is pleased to announce the approval of Federal Information Processing Standard (FIPS) Publication 180-3, Secure Hash Standard (SHS), a revision of FIPS 180-2. The Federal Register Notice (FRN) of the approval is available here. [...]

The changes are listed here.

[...]Some technical information in FIPS 180–2 about the security of the hash algorithms may no longer be accurate, as shown by recent research results, and it is possible that further research may indicate additional changes. Therefore, the technical information has been removed from the revised standard, and will be provided in Special Publications (SPs) 800–107 and 800–57, which can be updated in a timely fashion as the technical conditions change.

And a draft of SP800-57 Part3 is now out for public comment.

NIST announces the release of a draft of Part 3 of Special Publication 800-57, Recommendation for Key Management: Application-Specific Key Management Guidance. This Recommendation provides guidance when using the cryptographic features of current systems. It is intended to help system administrators and system installers adequately secure applications based on product availability and organizational needs, and to support organizational decisions about future procurements. [...]

Update: EnRUPT has fallen.

Collisions have been found in ïrRUPT taking it out of the SHA-3 competition since tweaks or corrections will be allowed only for the 5 finalists.

Update: Or not. Just the EnRUPT/4 variant has been slain.

After studying Sebastiaan’s linearization attack in detail, we have come to the conclusion that EnRUPT does not require any structural changes, corrections or tweaks and that its dismissal is more than premature. It is only a matter of setting the ‘s’ parameter to a slightly higher value increasing the amount of diffusion in the state between inputs.

And, SP800-108 has been released.

November 6, 2008
The National Institute of Standards and Technology (NIST) is pleased to announce the release of Special Publication 800-108. Recommendation for Key Derivation Using Pseudorandom Functions. [...]

-

More cool, cool, cool. Since my last post way back when, the Petname Tool (mentioned here) has been updated to be compatible with Firefox 3.

Secure web sites identify themselves using cryptography. In a phishing attack, a thief tries to impersonate such a site by omitting the cryptographic identification, or using one that’s confusingly similar.

The Petname Tool can help you keep track of these cryptographic identifiers by letting you attach reminder notes to them. Before exchanging sensitive information with a site, you type in a name that will help you remember the site. From then on, whenever your browser is securely connected to that site, your name for it will be displayed. After following a hyperlink, just check that the Petname Tool is displaying the expected name. If so, the Petname Tool has checked that the cryptographic identifiers are also the expected ones.
Works with:

* Firefox: 3.0 – 3.0.*

And NoScript really has been plowing along. Good stuff.

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

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

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