As the special guest of the Foundation for Information Policy Research:
Richard Stallman
Founder of the GNU Project, and campaigner for free software which people are at liberty to copy, redistribute and change. Winner of Grace Hopper Award, Electronic Frontier Foundation's Pioneer award, and Takeda Award....
Software Patents - Obstacles to software development
Software patents are patents on software ideas. A typical computer program today combines many software ideas, just as a symphony combines many musical ideas. Inevitably most of them have to be old ideas. Software patents mean that every design decision brings with it a risk of getting sued.
This event will also see the launch of the "Friends of FIPR" - this will be your chance to become a founding supporter of the UK's only effective think tank addressing Internet issues.
On the other hand, Google listings appear to be quite stable for some subjects. Consider PuTTY, a Win32 ssh client and terminal emulator: the Google URL for it is actually shorter than its official URL (http://www.chiark.greenend.org.uk/~sgtatham/putty/).
Another TINI-based MP3 player is
here [greenend.org.uk], although it's still in the planning stages.
I'm unlikely to have enough time to finish this until at least June 2002. Anyone else is welcome to finish the design off - it just needs the PCB layout to be finished. (Most of the data lines are routed already, it just needs power connecting and decoupling capacitors adding.)
WLAN latency is BAD. 80+ milliseconds just to the AP.
myrddin:~$ ping lurker
PING lurker.sinister.greenend.org.uk (172.19.71.11): 56 data bytes
64 bytes from 172.19.71.11: icmp_seq=0 ttl=127 time=2.7 ms
64 bytes from 172.19.71.11: icmp_seq=1 ttl=127 time=2.7 ms
64 bytes from 172.19.71.11: icmp_seq=2 ttl=127 time=2.7 ms
64 bytes from 172.19.71.11: icmp_seq=3 ttl=127 time=2.7 ms
('myrddin' is on a 100Mbit/s ethernet; to get to 'lurker' it has to go through a Linux-based router and a Nokia access point, and across the air. By comparison, it's 0.5ms to the router, and 10ms to the first hop after the cable modem.)
Transmeta now appears to have a similar business model to ARM. They both design processors for the low-power, portable markets, but there are differences: Transmeta's processors are larger and faster, but use more power. ARM's processors are used in devices like mobile phones and organisers where low power consumption is vital, and pure speed is not important.
ARM have been doing extremely well so far with this business model...
Can't you just look at the header information, to see what version it was encrypted with?
It's a bit late by then - if the key was tampered with, and the version of PGP used to encrypt the data was vulnerable, then the data will be readable by whoever tampered with the key.
Of course, finding out that the key was tampered with (which you can do by checking for additional recipients in the encrypted message) is useful in itself.
In the MPAA vs 2600 case, it's the same thing. 2600 didn't do anything, just reported it, like this kid. Yet they are successfully sued. Not
only that, but this security hole that's being pointed out in PGP was clearly found (or at least researched) by the decompiling of the PGP
source and reverse-engineering it's storage specs, right?
Even if some of those specs are public, certainly the fact that PGP works this way is not published anywhere (previously) and someone had
to "hack" this system to get the info. Clearly illegal behaviour under the DCMA under any circumstance.
The PGP source code is available - no reverse-engineering was done. Ralf, the author of the original paper, explicitly says that his tests were done without looking at the source to PGP: he was just testing the behaviour experimentally. And anyway, PGP is not a system for controlling access to copyrighted works, so has little to do with the DMCA.
PGP-2.6.3ia UNIX (not vulnerable - doesn't support V4 signatures)
PGP-5.0i UNIX (not vulnerable)
PGP-5.5.3i WINDOWS (VULNERABLE)
PGP-6.5.1i WINDOWS (VULNERABLE)
GnuPG-1.0.1 UNIX (not vulnerable)
Well, call me a zealot, but I think I see a pattern emerging...
If you're referring to the fact that the vulnerable versions of PGP were tested running on Windows, you're not seeing a pattern. PGP-5.5.3i and PGP-6.5.1i running on Unix are just as vulnerable.
The reason that this vulnerability in PGP is serious is that you can't fix it by updating your copy: you have to ensure that everybody who might send you encrypted messages has a copy of PGP without the ADK bug. This is difficult, especially when you don't know who your correspondants are going to be ahead of time.
Here is a summary of Ralf's paper that I wrote while reading it yesterday:
When a PGP key-pair is generated, the public key is stored in a file
as a number of typed 'packets': the key itself, a userid, etc. One of
these packets is a signature of the previous packets made with the
private key, to bind them together (so that, for example, the userid
cannot be changed).
In PGP version 3 files, it's as simple as that.
In PGP version 4 files, the signature packet contains some extra
fields: two sets of 'subpackets'. One set of subpackets is included in
the hash, and therefore cannot be tampered with. The other is not
included in the hash.
Some versions of PGP allow "Additional Decryption Keys" to be
specified for public keys. They are specified by including the
additional key identity in a subpacket in the signature. The idea is
that when you create a key pair and sign the public part, you sign the
identities of any ADKs that you want to use. This is supposed to
prevent ADKs from being specified without the consent of the holder of
the private key.
Unfortunately, some versions of PGP respond to ADK subpackets in the
non-hashed part of the signature. This is a blatant bug. They treat
them exactly as if they were hashed, i.e. they show up as ADKs in the
list of 'key properties', and messages encrypted to the public key
include packets allowing the session key to be obtained by holders of
the ADKs.
Tested versions of PGP:
PGP-2.6.3ia UNIX (not vulnerable - doesn't support V4 signatures)
PGP-5.0i UNIX (not vulnerable)
PGP-5.5.3i WINDOWS (VULNERABLE)
PGP-6.5.1i WINDOWS (VULNERABLE)
GnuPG-1.0.1 UNIX (not vulnerable - doesn't support ADKs)
The problem won't go away until all vulnerable versions of PGP are
retired, since it's the sender who is responsible for encrypting to
the ADKs, not the recipient.
As far as I can tell, nobody has done the experiment of uploading a
modified signature packet to a keyserver yet - will it replace the
existing signature packet, or be ignored? (Or possibly be stored in
addition, in which case more experiments need to be done: what will
various versions of PGP do if given keys with multiple
self-signatures?)
More followup: I've found the bug in the PGP-6.5.1i-beta2 source
code. I'm fairly sure it will be identical in all the other vulnerable
versions.
In file libs/pgpcdk/priv/keys/keys/pgpRngPub.c, I see two functions:
one called ringKeyFindSubpacket(), which finds a subpacket from a
self-signature packet, and ringKeyAdditionalRecipientRequestKey(),
which uses ringKeyFindSubpacket() to search for ADK subpackets.
ringKeyFindSubpacket() is declared as follows:
PGPByte const *
ringKeyFindSubpacket (RingObject *obj, RingSet const *set,
int subpacktype, unsigned nth,
PGPSize *plen, int *pcritical, int *phashed, PGPUInt32 *pcreation,
unsigned *pmatches, PGPError *error);
In particular, the "phashed" parameter is used to return whether the
subpacket was in the hashed region. Now, looking at the call in
ringKeyAdditionalRecipientRequestKey() I see this:
...the "phashed" value isn't checked (or even asked for)!
Ok - it's an obvious implementation bug, and the bug itself should be easy to fix. I won't comment on the wisdom of designing in ADKs in the first place; the problem now is, how do we get everyone to replace their vulnerable copies of PGP? And, since that won't ever happen completely, how do we minimise the remaining problem?
It should be easy to spot keys that have been tampered with: use gpg --list-packets and look for ADKs in the unhashed section of the self-signature. You can also check to see whether you are receiving messages that have been encrypted to more than one recipient: look for multiple session key packets.
Finally, I recommend that regular sweeps are made of the public key servers for keys that have been tampered with.
Well, the phones have a whole stack of problems in their own right. First, any idiot can tune in to them (no encryption). Second, they interfere with each other a lot.
Not true, at least for DECT phones like the Siemens phone mentioned in the article. First of all, DECT is a frequency-agile standard (the handset continuously monitors the signal from the base station, and can initiate a handoff to another frequency/time slot or basestation if the quality drops too low). Second, the DECT standard defines authentication and encryption algorithms which are supposed to be supported by all DECT-compatible equipment.
Unfortunately, like all other ETSI encryption standards these are not publicly available, and as far as I know there has been no effort put into cryptanalysing them. If they are anything like other ETSI-sourced algorithms (for example those in use in the GSM system) they are probably full of holes.
Interestingly, Siemens claim to have implemented their own encryption algorithm in their GigaSet range of products, but since they don't publish the details they have exactly the same problem...
For those interested in the ancient art of reading, Greg Egan wrote an excellent Science Fiction book on this very topic called 'Permutation City'. (It should be available through your favorite bookseller)
This idea has cropped up in a lot of science fiction recently. Greg Egan also covers it in his novel 'Diaspora', as well as many short stories ('Learning to Be Me', 'Closer',...)
Peter Hamilton has an interesting take on the idea, which he explains in his "Night's Dawn" trilogy ('The Reality Dysfunction', 'The Neutronium Alchemist', 'The Naked God'; watch out, they are published as six books in America) and a few short stories ('A Second Chance at Eden'). The difference here is that in his universe, consciousness can only be downloaded into biological technology ("bitek") and not into normal machines.
Whether or not you buy the book, and whether or not you think of yourself as a programmer, if you consider yourself a thinking person, you should take this quiz. If you can't do back-of-the-envelope calculations, you should find this out as soon as possible, and fix the problem while you still can.
The problem I had with this quiz was that a lot of the questions assume American units and places. For example, I don't have a really good mental model of what weight a pound is, I don't know where Mississippi or Missouri are, and I've only heard of the Golden Gate bridge - I've never seen it.
How about some alternative questions:
January 1, 2000, population of the United Kingdom in millions
Why 96 kHz? Humans can only hear frequencies below 22kHz and the sampling theorem states that any band-limited signal can be completely specified by samples taken at twice the maximum frequency- implying a need for 44kHz max. So what's the extra 52 kHz for? I'm sceptical that the oversampling is to reduces noise since a wider filter can only increase the total noise power- not reduce it. I assume some practical reason exists.
The raw signal from the various instruments will pass through several layers of processing: mixing, filtering, effects processing, etc. At each of these stages distortion will be introduced (through rounding errors, etc.) - it's better to start out at high resolution and sample rate, have the distortion be small at each stage, and only reduce the resolution and sample rate for the final medium than it is to use the bare minimum rate all the way through the system and suffer larger (probably audible) distortions.
According to the specs (section 2.3), it uses plain old 100mb ethernet of it's electrical transport, so it looks like you could just plug one of their instruments into a standard 100mb nic, but I'm not certain if the nic will be able to handle the packets. However, it looks like MIDI control packets is explicitly supported, so all that should be needed is a dongle between your MIDI instrument and the GMICS network.
It's not compatible with 100Mbit Ethernet - they use the physical and electrical layers from the specification (sensible - there are a lot of cheap, readily-available components that deal with these), but not the data link layer. If you plug GMICS equipment into an Ethernet hub or network card, nothing will happen - the hub won't see a link heartbeat.
It's easy to imagine a device that has analogue and MIDI connectors on one side and a GMICS type A connector on the other side. It could be powered by the 'phantom power', and would make it trivial to interface an analogue instrument and existing effects boxes to a GMICS system.
(Incidentally, I think they are abusing the term 'phantom power' a little in the specification. It usually refers to power sent over an audio lead using the same conductor as the audio signal; at both ends the DC power is filtered out leaving the AC audio signal. The GMICS 'phantom power' is just sent using the four otherwise-unused conductors in a Category 5 cable.)
Why is it that whenever the government or a corporation tries to instate virtual communities with either tracking systems or any sort of personal information tracking, we all cry out "Big Brother" and the privacy advocates flip their lids. *BUT* when we see stories like this, we think that it's cool and we cheer it on?
It's all about who controls access to the information. If you carry a tracking device that belongs to you and is under your control, that's ok: you can consult the logs to find out who/what has requested information, define policy about how the information is to be given out, etc.
If the automation belongs to another body, like the government or the phone company, that's not good: you can't be sure what it is doing with your information.
The case where the collection of personal information depends on a larger infrastructure is an interesting one. Some people have put thought a certain amount of thought into this...
Re:Security 101... Not offered on campus.
on
Linux Lite?
·
· Score: 1
Sigh... sorry about the rant.
It sounds bad. I think we're quite lucky in Cambridge; the Computing Service is by and large very good.
We have an interesting arrangement in the University as far as computing is concerned. The Computing Service provides central services (the city-wide network, a central mail store and switches, a central Unix service, printroom facilities, archive services, etc.), but the various Colleges and Departments (and the University administration) are all responsible for their own systems. It has the potential to get very confusing, but in practice seems to work very well.
It's a "toy" system in the sense that you'd be insane to attempt to deploy it in a real-world situation. However, it's a very useful base for operating systems research, and even though it's five years old it still supports things that I've never seen on any other operating system.
Nemesis has a number of deficiencies which result from "interesting" design decisions, particularly (in my opinion) its inability to support confinement. I'm attempting to correct these, yet still retain many of Nemesis' good points, in my new operating system Mimesis.
Re:Security 101... Not offered on campus.
on
Linux Lite?
·
· Score: 1
It's not always that bleak. At the University of Cambridge the computing service regularly scan the network using a variety of tools (including script-kiddie ones) and do their best to make sure that vulnerable machines are fixed.
This isn't a perfect solution, of course, but it does mean that most of the exploits in common use won't work against most machines in Cambridge. There is also a site-wide firewall that is used to block some services that are regularly abused.
In A Deepness In The Sky by Vernor Vinge (a prequel to A Fire Upon The Deep) the (relatively) 'bad' guys turn a part of their population (and anybody else's if they can get their hands on them) into 'focussed' specialists by artificially causing a form of autism. The specialists have no life outside work at all; they become completely obsessed by their particular topic. A large part of the book is dedicated to exploring the social consequences of this practice.
If you intend to read both books then read them in the order they were published, even though A Fire Upon The Deep doesn't really contain anything relevant to this article.
Provided that they implement the system correctly, it will be more secure than current credit card systems.
In a traditional credit card system, all you need to know to make a purchase with the card is the card number and expiry date (and possibly also the name on the card and the address at which it is registered). These are easily visible on the card, and readable from the magnetic strip. They are sent to the merchant whenever you make a credit card transaction of any kind.
The problem with this is obvious: you do not need the card to be present to make a purchase. Embedding a chip in the card enables us to be a little more clever.
If AmEx have implemented the scheme sensibly then the chip embedded in the card will be a small microprocessor. It will have some non-volatile memory for key storage, some volatile memory for working storage, and probably some hardware crypto acceleration (because implementing crypto in software on slow microprocessors yields poor performance). The chip will be designed such that it is difficult (i.e. expensive, time-consuming and obvious that it has taken place) to read out the contents of the memory.
When an online purchase takes place, the details of the purchase (merchant ID, amount of transaction, etc.) will be sent to the customer's computer. To complete the purchase the details must be sent to the card, which will perform some cryptographic operation and return some more data which must be sent back to the merchant. (The precise details will depend on the implementation.) The point of the whole scheme, and the reason that it is more secure, is that the data returned to the merchant depends on key material embedded in the chip.
It is still possible to attack systems like this, either by exploiting errors in the system design or implementation, or by physically attacking the smartcard. See this widely-cited paper for more information and references.
Yes, it's the undergraduate Computer Science course at Cambridge. It's generally taken by people who have just done A-levels and left school, i.e. most people are 18 when they start the course.
There is a reduced version of the course for people who have already done a first degree; the Diploma in Computer Science takes just one year. There's a similar one-year course for people already at Cambridge who have spent two years on another course (part of the Natural Sciences tripos, for example, or mathematics) and want to switch.
Slashdot Mirror
"I didn't get your message. And furthermore, you were out when I tried to reply."
Here are the details of the talk on the 25th.
As the special guest of the Foundation for Information Policy Research:
Richard Stallman Software Patents - Obstacles to software development Date: Monday 25th March 2002Time: 16:15-17:30
Venue: Large Lecture Theatre, University of Cambridge Computer Laboratory
Directions: http://www.cl.cam.ac.uk/UoCCL/contacts/
Poster: http://www.fipr.org/stallman.html
This event will also see the launch of the "Friends of FIPR" - this will be your chance to become a founding supporter of the UK's only effective think tank addressing Internet issues.
All are welcome!
999 (in case its in Europe)
The emergency number in Europe is officially 112. "999" works in the UK, but is unlikely to work in other European countries.
On the other hand, Google listings appear to be quite stable for some subjects. Consider PuTTY, a Win32 ssh client and terminal emulator: the Google URL for it is actually shorter than its official URL (http://www.chiark.greenend.org.uk/~sgtatham/putty /).
IBM obviously didn't check Google before naming their project. GNU userv got there first (in 1996).
WLAN latency is BAD. 80+ milliseconds just to the AP.
myrddin:~$ ping lurker
PING lurker.sinister.greenend.org.uk (172.19.71.11): 56 data bytes
64 bytes from 172.19.71.11: icmp_seq=0 ttl=127 time=2.7 ms
64 bytes from 172.19.71.11: icmp_seq=1 ttl=127 time=2.7 ms
64 bytes from 172.19.71.11: icmp_seq=2 ttl=127 time=2.7 ms
64 bytes from 172.19.71.11: icmp_seq=3 ttl=127 time=2.7 ms
('myrddin' is on a 100Mbit/s ethernet; to get to 'lurker' it has to go through a Linux-based router and a Nokia access point, and across the air. By comparison, it's 0.5ms to the router, and 10ms to the first hop after the cable modem.)
Transmeta now appears to have a similar business model to ARM. They both design processors for the low-power, portable markets, but there are differences: Transmeta's processors are larger and faster, but use more power. ARM's processors are used in devices like mobile phones and organisers where low power consumption is vital, and pure speed is not important.
ARM have been doing extremely well so far with this business model...
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
Can't you just look at the header information, to see what version it was encrypted with?
It's a bit late by then - if the key was tampered with, and the version of PGP used to encrypt the data was vulnerable, then the data will be readable by whoever tampered with the key.
Of course, finding out that the key was tampered with (which you can do by checking for additional recipients in the encrypted message) is useful in itself.
In the MPAA vs 2600 case, it's the same thing. 2600 didn't do anything, just reported it, like this kid. Yet they are successfully sued. Not only that, but this security hole that's being pointed out in PGP was clearly found (or at least researched) by the decompiling of the PGP source and reverse-engineering it's storage specs, right?
Even if some of those specs are public, certainly the fact that PGP works this way is not published anywhere (previously) and someone had to "hack" this system to get the info. Clearly illegal behaviour under the DCMA under any circumstance.
The PGP source code is available - no reverse-engineering was done. Ralf, the author of the original paper, explicitly says that his tests were done without looking at the source to PGP: he was just testing the behaviour experimentally. And anyway, PGP is not a system for controlling access to copyrighted works, so has little to do with the DMCA.
If you're referring to the fact that the vulnerable versions of PGP were tested running on Windows, you're not seeing a pattern. PGP-5.5.3i and PGP-6.5.1i running on Unix are just as vulnerable.
The reason that this vulnerability in PGP is serious is that you can't fix it by updating your copy: you have to ensure that everybody who might send you encrypted messages has a copy of PGP without the ADK bug. This is difficult, especially when you don't know who your correspondants are going to be ahead of time.
Here is a summary of Ralf's paper that I wrote while reading it yesterday:
More followup: I've found the bug in the PGP-6.5.1i-beta2 source code. I'm fairly sure it will be identical in all the other vulnerable versions.
In file libs/pgpcdk/priv/keys/keys/pgpRngPub.c, I see two functions: one called ringKeyFindSubpacket(), which finds a subpacket from a self-signature packet, and ringKeyAdditionalRecipientRequestKey(), which uses ringKeyFindSubpacket() to search for ADK subpackets.
ringKeyFindSubpacket() is declared as follows:
PGPByte const * ringKeyFindSubpacket (RingObject *obj, RingSet const *set, int subpacktype, unsigned nth, PGPSize *plen, int *pcritical, int *phashed, PGPUInt32 *pcreation, unsigned *pmatches, PGPError *error);
In particular, the "phashed" parameter is used to return whether the subpacket was in the hashed region. Now, looking at the call in ringKeyAdditionalRecipientRequestKey() I see this:
krpdata = ringKeyFindSubpacket (obj, set, SIGSUB_KEY_ADDITIONAL_RECIPIENT_REQUEST, nth, &krdatalen, &critical, NULL, NULL, &matches, error);
...the "phashed" value isn't checked (or even asked for)!
Ok - it's an obvious implementation bug, and the bug itself should be easy to fix. I won't comment on the wisdom of designing in ADKs in the first place; the problem now is, how do we get everyone to replace their vulnerable copies of PGP? And, since that won't ever happen completely, how do we minimise the remaining problem?
It should be easy to spot keys that have been tampered with: use gpg --list-packets and look for ADKs in the unhashed section of the self-signature. You can also check to see whether you are receiving messages that have been encrypted to more than one recipient: look for multiple session key packets.
Finally, I recommend that regular sweeps are made of the public key servers for keys that have been tampered with.
Well, the phones have a whole stack of problems in their own right. First, any idiot can tune in to them (no encryption). Second, they interfere with each other a lot.
Not true, at least for DECT phones like the Siemens phone mentioned in the article. First of all, DECT is a frequency-agile standard (the handset continuously monitors the signal from the base station, and can initiate a handoff to another frequency/time slot or basestation if the quality drops too low). Second, the DECT standard defines authentication and encryption algorithms which are supposed to be supported by all DECT-compatible equipment.
Unfortunately, like all other ETSI encryption standards these are not publicly available, and as far as I know there has been no effort put into cryptanalysing them. If they are anything like other ETSI-sourced algorithms (for example those in use in the GSM system) they are probably full of holes.
Interestingly, Siemens claim to have implemented their own encryption algorithm in their GigaSet range of products, but since they don't publish the details they have exactly the same problem...
The .god domain, for example, says "first come, first serve".. and that is the registration policy.
bash$ host -t ns god.god does not exist, try again
For those interested in the ancient art of reading, Greg Egan wrote an excellent Science Fiction book on this very topic called 'Permutation City'. (It should be available through your favorite bookseller)
This idea has cropped up in a lot of science fiction recently. Greg Egan also covers it in his novel 'Diaspora', as well as many short stories ('Learning to Be Me', 'Closer', ...)
Peter Hamilton has an interesting take on the idea, which he explains in his "Night's Dawn" trilogy ('The Reality Dysfunction', 'The Neutronium Alchemist', 'The Naked God'; watch out, they are published as six books in America) and a few short stories ('A Second Chance at Eden'). The difference here is that in his universe, consciousness can only be downloaded into biological technology ("bitek") and not into normal machines.
The problem I had with this quiz was that a lot of the questions assume American units and places. For example, I don't have a really good mental model of what weight a pound is, I don't know where Mississippi or Missouri are, and I've only heard of the Golden Gate bridge - I've never seen it.
How about some alternative questions:
The raw signal from the various instruments will pass through several layers of processing: mixing, filtering, effects processing, etc. At each of these stages distortion will be introduced (through rounding errors, etc.) - it's better to start out at high resolution and sample rate, have the distortion be small at each stage, and only reduce the resolution and sample rate for the final medium than it is to use the bare minimum rate all the way through the system and suffer larger (probably audible) distortions.
It's not compatible with 100Mbit Ethernet - they use the physical and electrical layers from the specification (sensible - there are a lot of cheap, readily-available components that deal with these), but not the data link layer. If you plug GMICS equipment into an Ethernet hub or network card, nothing will happen - the hub won't see a link heartbeat.
It's easy to imagine a device that has analogue and MIDI connectors on one side and a GMICS type A connector on the other side. It could be powered by the 'phantom power', and would make it trivial to interface an analogue instrument and existing effects boxes to a GMICS system.
(Incidentally, I think they are abusing the term 'phantom power' a little in the specification. It usually refers to power sent over an audio lead using the same conductor as the audio signal; at both ends the DC power is filtered out leaving the AC audio signal. The GMICS 'phantom power' is just sent using the four otherwise-unused conductors in a Category 5 cable.)
It's all about who controls access to the information. If you carry a tracking device that belongs to you and is under your control, that's ok: you can consult the logs to find out who/what has requested information, define policy about how the information is to be given out, etc.
If the automation belongs to another body, like the government or the phone company, that's not good: you can't be sure what it is doing with your information.
The case where the collection of personal information depends on a larger infrastructure is an interesting one. Some people have put thought a certain amount of thought into this...
We have an interesting arrangement in the University as far as computing is concerned. The Computing Service provides central services (the city-wide network, a central mail store and switches, a central Unix service, printroom facilities, archive services, etc.), but the various Colleges and Departments (and the University administration) are all responsible for their own systems. It has the potential to get very confusing, but in practice seems to work very well.
It's a "toy" system in the sense that you'd be insane to attempt to deploy it in a real-world situation. However, it's a very useful base for operating systems research, and even though it's five years old it still supports things that I've never seen on any other operating system.
Nemesis has a number of deficiencies which result from "interesting" design decisions, particularly (in my opinion) its inability to support confinement. I'm attempting to correct these, yet still retain many of Nemesis' good points, in my new operating system Mimesis.
This isn't a perfect solution, of course, but it does mean that most of the exploits in common use won't work against most machines in Cambridge. There is also a site-wide firewall that is used to block some services that are regularly abused.
In A Deepness In The Sky by Vernor Vinge (a prequel to A Fire Upon The Deep) the (relatively) 'bad' guys turn a part of their population (and anybody else's if they can get their hands on them) into 'focussed' specialists by artificially causing a form of autism. The specialists have no life outside work at all; they become completely obsessed by their particular topic. A large part of the book is dedicated to exploring the social consequences of this practice.
If you intend to read both books then read them in the order they were published, even though A Fire Upon The Deep doesn't really contain anything relevant to this article.
In a traditional credit card system, all you need to know to make a purchase with the card is the card number and expiry date (and possibly also the name on the card and the address at which it is registered). These are easily visible on the card, and readable from the magnetic strip. They are sent to the merchant whenever you make a credit card transaction of any kind.
The problem with this is obvious: you do not need the card to be present to make a purchase. Embedding a chip in the card enables us to be a little more clever.
If AmEx have implemented the scheme sensibly then the chip embedded in the card will be a small microprocessor. It will have some non-volatile memory for key storage, some volatile memory for working storage, and probably some hardware crypto acceleration (because implementing crypto in software on slow microprocessors yields poor performance). The chip will be designed such that it is difficult (i.e. expensive, time-consuming and obvious that it has taken place) to read out the contents of the memory.
When an online purchase takes place, the details of the purchase (merchant ID, amount of transaction, etc.) will be sent to the customer's computer. To complete the purchase the details must be sent to the card, which will perform some cryptographic operation and return some more data which must be sent back to the merchant. (The precise details will depend on the implementation.) The point of the whole scheme, and the reason that it is more secure, is that the data returned to the merchant depends on key material embedded in the chip.
It is still possible to attack systems like this, either by exploiting errors in the system design or implementation, or by physically attacking the smartcard. See this widely-cited paper for more information and references.
This is an undergrad degree?
Yes, it's the undergraduate Computer Science course at Cambridge. It's generally taken by people who have just done A-levels and left school, i.e. most people are 18 when they start the course.
There is a reduced version of the course for people who have already done a first degree; the Diploma in Computer Science takes just one year. There's a similar one-year course for people already at Cambridge who have spent two years on another course (part of the Natural Sciences tripos, for example, or mathematics) and want to switch.