Re: I don't know PAIN...
On Sat, 2003-12-20 at 09:03, Ian Grigg wrote: What is the source of the acronym PAIN? I.e., its provenance? Google shows only a few hits, indicating it is not widespread. iang I just tried +security +pain +privacy +authentication +integrity on alta vista and it claims to have over 1000 results quick sample ... some of them involve pain of security or pain of security risks (not all of them are referring to the acronym) on google doing +security +pain +privacy +authentication +integrity +non-repudation gets 22 screens of 10 entries each ... although some aren't using PAIN as an acronym -- Anne Lynn Wheeler - http://www.garlic.com/~lynn/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Difference between TCPA-Hardware and a smart card (was:example: secure computing kernel needed)
Anne Lynn Wheeler wrote: At issue in business continuity are business requirements for things like no single point of failure, offsite storage of backups, etc. The threat model is 1) data in business files can be one of its most valuable assets, 2) it can't afford to have unauthorized access to the data, 3) it can't afford to loose access to data, 4) encryption is used to help prevent unauthorized access to the data, 5) if the encryption keys are protected by a TCPA chip, are the encryption keys recoverable if the TCPA chip fails? You may have hit upon something there, Lynn. One of the (many) reasons that PKI failed is that businesses simply don't outsource trust. If the use of TCPA is such that the business must trust in its workings, then it can fairly easily be predicted that it won't happen. For business, at least (that still leaves retail and software sales based on IP considerations). It is curious that in the IT trust business, there seems to be a continuing supply of charlatan ventures. Even as news of PKI slinking out of town reaches us, people are lining up to buy tickets for the quantum crypotagraphy miracle cure show and bottles of the new wonder TCPA elixir. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Difference between TCPA-Hardware and other forms of trust
Bill Frantz wrote: [I always considered the biggest contribution from Mondex was the idea of deposit-only purses, which might reduce the incentive to rob late-night business.] This was more than just a side effect, it was also the genesis of the earliest successes with smart card money. The first smart card money system in the Netherlands was a service-station system for selling fuel to truck drivers. As security costs kept on rising, due to constant hold-ups, the smart card system was put in to create stations that had no money on hand, so no need for guards or even tellers. This absence of night time staff created a great cost saving, and the programme was a big success. Unfortunately, the early lessons were lost as time went on, and attention switched from single-purpose to multi-purpose applications. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Carl Ellison wrote: We see here a difference between your and my sides of the Atlantic. Here in the US, almost no one has a smart card. Of those cards you carry, how many are capable of doing public key operations? A simple memory smartcard doesn't count for what we were talking about. I don't know. If you can tell me how to find out, I'd be happy to investigate. I have quite a few that are no longer needed, so destructive investigation is possible :-) BTW, I forgot the two smartcards that are used by my Sky satellite TV stuff. There are other problems with doing TCPA-like operations with a smartcard, but I didn't go into those. The biggest one to chew on is that I, the computer owner, need verification that my software is in good shape. My agent in my computer (presumably the smartcard) needs a way to examine the software state of my computer without relying on any of the software in my computer (which might have been corrupted, if the computer's S/W has been corrupted). This implies to me that my agent chip needs a H/W path for examining all the S/W of my computer. That's something the TPM gives us that a smartcard doesn't (when that smartcard goes through a normal device driver to access its machine). I'm not arguing with this - just the economic argument about number of smartcards. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: I don't know PAIN...
Ian Grigg wrote: What is the source of the acronym PAIN? Lynn said: ... A security taxonomy, PAIN: * privacy (aka thinks like encryption) * authentication (origin) * integrity (contents) * non-repudiation I.e., its provenance? Google shows only a few hits, indicating it is not widespread. Probably because non-repudiation is a stupid idea: http://www.apache-ssl.org/tech-legal.pdf. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Difference between TCPA-Hardware and other forms of trust
bear wrote: I really don't care if anyone *else* trusts my system; as far as I'm concerned, their secrets should not be on my system in the first place, any more than my secrets should be on theirs. The problem is that their secrets are Snow White, or the latest Oasis album. You want them on your box, and they want them not to leave your box. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Difference between TCPA-Hardware and other forms of trust
Bill Frantz wrote: One should note that TCPA is designed to store its data (encrypted) in the standard file system, so standard backup and restore techniques can be used. Only if your box doesn't die. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: example: secure computing kernel needed
Remote attestation has use in applications requiring accountability of the user, as a way for cooperating processes to satisfy themselves that configurations and state are as they're expected to be, and not screwed up somehow. There are many business uses for such things, like checking to see if locked down kiosk computers have been modified (either hardware or software), verifying that users have not excercised their god-given right to install spy-ware and viruses (since they're running with administrative priviledges, aren't they?), and satisfying a consumer that the server they're connected to is (or isn't) running software that records has adequate security domain protections to protect the users data (perhaps backup files) the user entrusts to the server. What I'm not sure of is whether there are any anonymous / privacy enhancing scenarios in which remote attestation is useful. Well, the last case, above, where the server is attesting to the client could work. But what about the other way around. The assumption I have is that any remote attestation, even if anonymous, still will leave a trail that might be used by forensic specialists for some form of traffic analysis, if nothing else. In that case, you'd need to trust your trusted computing system not to provide remote attestation without your explicit assent. I'd really like to see an open source effort to provide a high assurance TPM implementation, perhaps managed through a Linux 2.6 / LSM / TPM driver talking to a TPM module. Yes, the TPM identity and integrity will still be rooted in its manufacturer (IBM, Intel, Asus, SiS, whomever). But hell, we're already trusting them not to put tcpstacks into the BIOS for PAL chips to talk to their evil bosses back in [fill in location of your favorite evil empire, here]. Oh, wait a minute - Phoenix is working on that, too, aren't they? I see the TPM configuration management tool as a way to provide a trusted boot path, complete with automagical inventory of approved hardware devices, so that evaluated operating systems, like Solaris and Linux, can know whether they're running on hardware whose firmware and circuitry are known (or believed) not to have been subverted, or to have certain EMI / Tempest characteristics. Mass market delivery of what are ususally statically configured systems that still retain their C2/CC-EAL4 ratings. But more important is where TPM and TCPA lead Intel and IBM, towards increasing virtualization of commodity hardware, like Intel's LeGrand strategy to restore a trusted protection ring (-1) to their processors, which will make it easier to get real, proper virtualization with trusted hypervisors back into common use. The fact that Hollywood thinks they can use the technology, and thus they're willing to underwrite its development, is fortuitous, as long as the trust is based on open transparent reviews and certifications. Maybe the FSF and EFF will create their own certification program, to review and bless TPM ring -1 implementations, just to satsify the slashdot crowd... Maybe they should. Ed William Arbaugh [EMAIL PROTECTED] 12/18/2003 5:33:00 PM On Dec 16, 2003, at 5:14 PM, David Wagner wrote: Jerrold Leichter wrote: We've met the enemy, and he is us. *Any* secure computing kernel that can do the kinds of things we want out of secure computing kernels, can also do the kinds of things we *don't* want out of secure computing kernels. I don't understand why you say that. You can build perfectly good secure computing kernels that don't contain any support for remote attribution. It's all about who has control, isn't it? There is no control of your system with remote attestation. Remote attestation simply allows the distant end of a communication to determine if your configuration is acceptable for them to communicate with you. As such, remote attestation allows communicating parties to determine with whom they communicate or share services. In that respect, it is just like caller id. People should be able to either attest remotely, or block it just like caller id. Just as the distant end can choose to accept or not accept the connection. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: I don't know PAIN...
At 03:03 AM 12/21/2003, Ian Grigg wrote: What is the source of the acronym PAIN? I've seen, for many years, the acronym CAIN, where the C is Confidentiality. I think that was in the Orange Book. There's also, historically, an R for Robustness or Reliability in many military contexts, instead of the N for Nonrepudiation. That is, protection from denial-of-service attacks. Lastly, the A is often Authorization rather than Authentication, since integrity implies identification of the source. The first time I recall seeing PAIN was just a few weeks ago, in postings by Lynn. I don't know if that helps, because I certainly got mightily confused while writing it. Greg. Lynn said: ... A security taxonomy, PAIN: * privacy (aka thinks like encryption) * authentication (origin) * integrity (contents) * non-repudiation I.e., its provenance? Google shows only a few hits, indicating it is not widespread. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/ Gladesville NSW 2111232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Difference between TCPA-Hardware and a smart card (was: example:secure computing kernel needed)
At 09:38 AM 12/16/2003 -0500, Ian Grigg wrote: In the late nineties, the smart card world worked out that each smart card was so expensive, it would only work if the issuer could do multiple apps on each card. That is, if they could share the cost with different uses (or users). Of course, at this point the assertion that a smart card (that doesn't also have independent user I/O) costs enough to care about is pretty bogus. Dumb smartcards are cost-effective enough to use them to carry $5 in telephone minutes. The real constraint is that you're unlikely to have more than one card reader in a machine, so multifunction cards provide the opportunity to run multiple applications without switching cards in and out, but that only works if the application vendors cooperate. For instance, you may have some encrypted session application that needs to have your card stay in the machine during the session (e.g. VOIP, or secure login, SSH-like things, remote file system access), and you may want to pay for something using your bank smartcard during the session. That's not likely to work out, because the secure session software vendors are unlikely to have a relationship with your bank that lets both of them trust each other with their information, compared to the simpliciy of having multiple cards. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: example: secure computing kernel needed
William Arbaugh wrote: On Dec 16, 2003, at 5:14 PM, David Wagner wrote: Jerrold Leichter wrote: We've met the enemy, and he is us. *Any* secure computing kernel that can do the kinds of things we want out of secure computing kernels, can also do the kinds of things we *don't* want out of secure computing kernels. I don't understand why you say that. You can build perfectly good secure computing kernels that don't contain any support for remote attribution. It's all about who has control, isn't it? There is no control of your system with remote attestation. Remote attestation simply allows the distant end of a communication to determine if your configuration is acceptable for them to communicate with you. But you missed my main point. Leichter claims that any secure kernel is inevitably going to come with all the alleged harms (DRM, lock-in, etc.). My main point is that this is simply not so. There are two very different pieces here: that of a secure kernel, and that of remote attestation. They are separable. TCPA and Palladium contain both pieces, but that's just an accident; one can easily imagine a Palladium-- that doesn't contain any support for remote attestation whatsoever. Whatever you think of remote attestation, it is separable from the goal of a secure kernel. This means that we can have a secure kernel without all the harms. It's not hard to build a secure kernel that doesn't provide any form of remote attestation, and almost all of the alleged harms would go away if you remove remote attestation. In short, you *can* have a secure kernel without having all the kinds of things we don't want. Leichter's claim is wrong. This is an important point. It seems that some TCPA and Palladium advocates would like to tie together security with remote attestion; it appears they would like you to believe you can't have a secure computer without also enabling DRM, lock-in, and the other harms. But that's simply wrong. We can have a secure computer without enabling all the alleged harms. If we don't like the effects of TCPA and Palladium, there's no reason we need to accept them. We can have perfectly good security without TCPA or Palladium. As for remote attestion, it's true that it does not directly let a remote party control your computer. I never claimed that. Rather, it enables remote parties to exert control over your computer in a way that is not possible without remote attestation. The mechanism is different, but the end result is similar. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
The PAIN mnemonic
A security taxonomy, PAIN: * privacy (aka thinks like encryption) * authentication (origin) * integrity (contents) * non-repudiation Sorry, Lynn, but I don't buy this. It's missing replay prevention (freshness) and it included non-repudiation which is an unachievable, nonsense concept. If you want to keep the mnemonic, you can change the 4th one to non-replay. - Carl +--+ |Carl M. Ellison [EMAIL PROTECTED] http://theworld.com/~cme | |PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Non-repudiation (was RE: The PAIN mnemonic)
-Original Message- From: Anne Lynn Wheeler [mailto:[EMAIL PROTECTED] Sent: Sunday, December 21, 2003 6:42 AM To: Carl Ellison Cc: 'Anne Lynn Wheeler'; [EMAIL PROTECTED] Subject: Re: The PAIN mnemonic At 11:20 PM 12/20/2003 -0800, Carl Ellison wrote: and it included non-repudiation which is an unachievable, nonsense concept. one could look at one aspect of non-repudiation as the requirement for everybody having a unique pin/password with guidelines never to share pin/passwords ... which could be considered across a broad range of security activities. That's an interesting definition, but you're describing a constraint on the behavior of a human being. This has nothing to do with cryptosystem choice or network protocol design. What mechanisms do you suggest for enforcing even the constraint you cite? Of course, that constraint isn't enough. In order to achieve non-repudiation, the way it is defined, you need to prove to a third party (the judge) that a particular human being knowingly caused a digital signature to be made. A signature can be made without the conscious action of the person to whom that key has been assigned in a number of ways, none of which includes negligence by that person. Let's just leave the term non-repudiation to be used by people who don't understand security, but rather mouth things they've read in books that others claim are authoritative. There are lots of those books listing non-repudiation as a feature of public key cryptography, for example, and many listing it as an essential security characteristic. All of that is wrong, of course, but it's a test for the reader to see through it. - Carl +--+ |Carl M. Ellison [EMAIL PROTECTED] http://theworld.com/~cme | |PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Non-repudiation (was RE: The PAIN mnemonic)
At 08:23 AM 12/21/2003 -0800, Carl Ellison wrote: That's an interesting definition, but you're describing a constraint on the behavior of a human being. This has nothing to do with cryptosystem choice or network protocol design. What mechanisms do you suggest for enforcing even the constraint you cite? Of course, that constraint isn't enough. In order to achieve non-repudiation, the way it is defined, you need to prove to a third party (the judge) that a particular human being knowingly caused a digital signature to be made. A signature can be made without the conscious action of the person to whom that key has been assigned in a number of ways, none of which includes negligence by that person. Let's just leave the term non-repudiation to be used by people who don't understand security, but rather mouth things they've read in books that others claim are authoritative. There are lots of those books listing non-repudiation as a feature of public key cryptography, for example, and many listing it as an essential security characteristic. All of that is wrong, of course, but it's a test for the reader to see through it. I mentioned PAIN as a (in-use) security taxonomy ... not a cryptosystem taxonomy or network protocol taxonomy ... and there is nothing precluding human factors in a security paradigm (like human factors issues of requiring unique shared-secret for every security domain leading to humans having to fumble around with scores of shared-secrets). i agreee that non-repudiation has been seriously mis-used especially with regard to crypto systems. I've even made the assertion that possibly some of it can be contributed to having the word signature occur in both the term digital signature and legal signature even tho the two may have nothing at all to do with each other. note, however, when I did reference PAIN as (one possible) security taxonomy i tended to skip over the term non-repudiation and primarily made references to privacy, authentication, and integrity. sample of some past posts in various venues on the subject. http://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aepay7.htm#nonrep2 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign http://www.garlic.com/~lynn/aadsm12.htm#38 Legal entities who sign http://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI not working http://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards http://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards http://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda) http://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards http://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
RE: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Seth, that was a very good and interesting reply. Thank you. IBM has started rolling out machines that have a TPM installed. If other companies do that too (and there might be others that do already - since I don't follow this closely) then gradually the installed base of TPM-equipped machines will grow. It might take 10 years - or even more - before every machine out there has a TPM. However, that day may well come. Then again, TPMs cost money and I don't know any private individuals who are willing to pay extra for a machine with one. Given that, it is unlikely that TPMs will actually become a popular feature. Some TPM-machines will be owned by people who decide to do what I suggested: install a personal firewall that prevents remote attestation. With wider dissemination of your reasoning, that number might be higher than it would be otherwise. Meanwhile, there will be hackers who accept the challenge of defeating the TPM. There will be TPM private keys loose in the world, operated by software that has no intention of telling the truth to remote challengers. There might even be one or more web services out there with a pool of such keys, offering to do an attestation for you telling whatever lie you want to tell. With such a service in operation, it is doubtful that a service or content provider would put much faith in remote attestation - and that, too, might kill the effort. At this point, a design decision by the TCPA (TCG) folks comes into play. There are ways to design remote attestation that preserve privacy and there are ways that allow linkage of transactions by the same TPM. If the former is chosen, then the web service needs very few keys. If the privacy protection is perfect, then the web service needs only 1 key. If the privacy violation is very strong, then the web service won't work, but the TCG folks will have set themselves up for a massive political campaign around its violation of user privacy. Either of these outcomes will kill the TCG, IMHO. This is the reason that, when I worked for a hardware company active in the TCPA(TCG), I argued strongly against supporting remote attestation. I saw no way that it could succeed. Meanwhile, I am no longer in that company. I have myself to look out for. If I get a machine with a TPM, I will make sure I have the firewall installed. I will use the TPM for my own purposes and let the rest of the world think that I have an old machine with no TPM. You postulated that someday, when the TPM is ubiquitous, some content providers will demand remote attestation. I claim it will never become ubiquitous, because of people making my choice - and because it takes a long time to replace the installed base - and because the economic model for TPM deployment is seriously flawed. If various service or content providers elect not to allow me service unless I do remote attestation, I then have 2 choices: use the friendly web service that will lie for me - or decline the content or service. The scare scenario you paint is one in which I am the lone voice of concern floating in a sea of people who will happily give away their privacy and allow some service or content provider to demand this technology on my end. In such a society, I would stand out and be subject to discrimination. This is not a technical problem. This is a political problem. If that is a real danger, then we need to educate those people. RIAA and MPAA have been hoping for some technological quick fix to let them avoid facing the hard problem of dealing with people who don't think the way they would like people to think. It seems to me that you and John Gilmore and others are doing exactly the same thing - hoping for technological censorship to succeed so that you can avoid facing the hard problem of dealing with people who don't think the way they should (in this case, the people who happily give away their privacy and accept remote attestation in return for dancing pigs). I don't have the power to stop this technology if folks decide to field it. I have only my own reason and skills. - Carl +--+ |Carl M. Ellison [EMAIL PROTECTED] http://theworld.com/~cme | |PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ -Original Message- From: Seth David Schoen [mailto:[EMAIL PROTECTED] On Behalf Of Seth David Schoen Sent: Sunday, December 21, 2003 3:03 PM To: Carl Ellison Cc: 'Stefan Lucks'; [EMAIL PROTECTED] Subject: Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
IP2Location.com Releases Database to Identify IP's Geography
--- begin forwarded text Status: U Date: Wed, 17 Dec 2003 22:16:57 -0800 To: MacDev-1 (Moderated) [EMAIL PROTECTED] From: MacDev-1 Moderator [EMAIL PROTECTED] Subject: IP2Location.com Releases Database to Identify IP's Geography Sender: [EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] This message comes to you from MacDev-1(tm) -- the Mac(tm) OS Developer News and Info server. See below for more info on this list (including sub/unsub details). __ FOR IMMEDIATE RELEASE IP2Location.com Releases Database to Identify Geographical Location of Internet Address SARASOTA, Fla., Dec. 17, 2003 -- IP2Location.com, a leading technology provider of Internet geo-location software and services for the e-commerce industry, today announced the release of a new database in the IP2Location's award-winning product series. IP2Location(TM) is a database product that enables Web sites to identify the geographic location of their visitors using IP addresses. The database is used to match an incoming IP (internet protocol) address to the country, region, state, city, latitude, longitude and Internet service provider (ISP) of the Internet user. By knowing the location of visitors in real time, Web sites can display localized content, server bandwidth balancing, improve click-throughs and sales, prevent Internet fraud, and implement many other solutions. For the advertising and marketing industry, learning your Web visitor's origin enables you to offer unique banners to increase hits rate and ROI, customize marketing messages, redirect visitors to appropriate Web pages, display native language, or manage digital rights. For e-business Web sites, the IP2Location(TM) database is crucial to identify suspicious Internet orders to reduce charge-backs, avoid orders from high risk countries, display native currency on order forms, and calculate correct tax fees based on country and regions. The unique value of the Internet intelligence is that IP2Location gives us the ability to target location-aware messages directly to consumers, said Danny Wong, vice president of IIA Advertising Inc. With IP2Location's technology, we can better understand who and how people use our Web sites and then, in turn, offer advertisers the ability to deliver specific marketing messages to specific groups of consumers based on location. The IP2Location(TM) database contains more than 2.5 million records for all IP addresses. It has over 95 percent matching accuracy at the country level. Available at only US$499 per year, the database is available via download with free twelve monthly updates. Data is in ASCII text format, compatible with popular database programs including Microsoft SQL, MySQL, Microsoft Access, Oracle, IBM DB2 and others. Free demo is available online at http://www.ip2location.com. About IP2Location.com Founded in 2001, IP2Location.com provides Internet infrastructure intelligence services to online businesses. IP2Location.com's products provide the geographic location of Web site visitors in real-time, enabling businesses to display localized content, bandwidth balancing, improve click-throughs and sales, prevent fraud, conduct site analysis and foster regulatory compliance. With over 500 industry leading customers, IP2Location.com is the geolocation market leader. IP2Location.com's main headquarters is located in Penang, Malaysia, with regional sales office located in Florida, United States. The company can be reached by fax at +1-775-719-3889, by email at [EMAIL PROTECTED], and on the Web at http://www.ip2location.com. __ Please visit our sponsors: RadGad(sm): The Place for Useful Gifts Gadgets.(sm) http://www.radgad.com/, mailto:[EMAIL PROTECTED], or 877-5-RADGAD MacTech(r) Magazine: The journal of Macintosh technology and development http://www.mactech.com, mailto:[EMAIL PROTECTED], or 805-494-9797 DevDepot(sm): Your Source for RAM, Technical Developer Products http://www.devdepot.com, mailto:[EMAIL PROTECTED] or call 877-DEPOT-NOW To submit a posting to MacDev-1, mailto:[EMAIL PROTECTED] To subscribe to MacDev-1, send mail to [EMAIL PROTECTED] with the SUBJECT line reading SUBSCRIBE MACDEV-1. To unsubscribe, the SUBJECT line should read UNSUBSCRIBE MACDEV-1. MacTech, Developer Depot, RadGad, and Xplain Corporation are not responsible for any errors, omissions, or other inaccuracies in this message. News may be propagated freely, but please attribute your source as MacTech Magazine, http://www.mactech.com. -- --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
Norwegian DVD Hacker Acquitted on Piracy Charges
http://online.wsj.com/article_print/0,,SB107210905212179600,00.html The Wall Street Journal December 22, 2003 11:25 a.m. EST Norwegian DVD Hacker Acquitted on Piracy Charges Associated Press OSLO, Norway -- Dealing another blow to the entertainment industry, an appeals court on Monday upheld the acquittal of a Norwegian man charged with piracy for releasing a program that could crack DVD security codes. Prosecutors had appealed Jon Lech Johansen's January acquittal of charges he violated Norway's data break-in laws with his DeCSS program. The prosecution wanted a 90-day suspended jail sentence, confiscation of computer equipment and a $2,940 fine. In her 30-minute ruling Monday, Judge Wenche Skjeggestad said Mr. Johansen could freely copy DVDs he bought and hadn't violated laws protecting intellectual property. Mr. Johansen, now 20, was 15 when he developed the program to watch movies on a Linux-based computer without DVD-viewing software. He posted it on the Internet in 1999 and became a hacker folk hero. The case was widely seen as a test of the country's computer-protection laws. Because the case is the first of its kind in Norway, prosecutors may decide to appeal to the country's supreme court. Prosecutor Inge Marie Sunde said it was too early to decide, but said it's a matter worth evaluating. Mr. Johansen's lawyer, Halvor Manshaus, said two acquittals within a year ought to be proof enough the case should be dropped. Mr. Johansen was in France for the Christmas holiday when the verdict was announced and was not immediately available for comment. Prosecutors charged Mr. Johansen after receiving a complaint from the Motion Picture Association of America and the DVD Copy Control Association, which licenses the film industry's Content Scrambling System, or CSS. Mr. Johansen's program is just one of many that can break the CSS, which prevents illegal copying and blocks the use of legitimate copies on unauthorized equipment. U.S. courts have generally favored Hollywood in cases involving DVD cracking programs. In August, the California Supreme Court held that courts may block Internet users from posting such programs on grounds it could violate trade-secret rights, though it ordered an appeals court to determine whether the code is still a protected trade secret given its widespread exposure. In 2001, the 2nd U.S. Circuit Court of Appeals in New York said postings of the encryption program violated the 1998 federal Digital Millennium Copyright Act, which prohibits the circumvention of copy controls along with discussions on how to do so. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Difference between TCPA-Hardware and other forms of trust
On Sat, 20 Dec 2003, Ian Grigg wrote: Bill Frantz wrote: [I always considered the biggest contribution from Mondex was the idea of deposit-only purses, which might reduce the incentive to rob late-night business.] ... The first smart card money system in the Netherlands was a service-station system for selling fuel to truck drivers. As security costs kept on rising, due to constant hold-ups, the smart card system was put in to create stations that had no money on hand, so no need for guards or even tellers. This absence of night time staff created a great cost saving, and the programme was a big success. Unfortunately, the early lessons were lost as time went on, and attention switched from single-purpose to multi-purpose applications. This underscores an important point. In security applications limitations are often a feature rather than a bug. We are accustomed to making things better by making them able to do more; but in some spaces it's actually better to use a solution that can do very little. Much of the current security/cryptography angst can be summed up as small, limited, simple systems work, but big, complex, general systems are very hard to get right or have unintended drawbacks. Often the very generality of such systems is a barrier to their wide adoption. I would say that if you want to make any money in cryptography and security (and make it honestly) you should pick one business application, with one threat model and one business model, and nail it. Add no features, nor even include any room in your design, that don't directly address *that* problem. When you are able to present people with a solution to one problem, which has no requirement of further involvement than solving that one problem and introduces no risks or interactions other than those flatly necessary to solve that one problem, then they'll pay for it. But when we start talking about multi-function cards, it becomes a tradeoff where I can't get anything I want without getting things I don't want or risking network effects that will lead to markets dominated by business models I don't want to deal with. It makes the buy decision complicated and fraught with risk. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Difference between TCPA-Hardware and a smart card (was: example:secure computing kernel needed)
Bill Stewart wrote: At 09:38 AM 12/16/2003 -0500, Ian Grigg wrote: In the late nineties, the smart card world worked out that each smart card was so expensive, it would only work if the issuer could do multiple apps on each card. That is, if they could share the cost with different uses (or users). Of course, at this point the assertion that a smart card (that doesn't also have independent user I/O) costs enough to care about is pretty bogus. Dumb smartcards are cost-effective enough to use them to carry $5 in telephone minutes. Sorry, yes, each actual smart card is, at the margin, cheap. But, as a project, the smart card is expensive. There's a big difference between project costs and the marginal cost, and that generally makes *the* difference. I suppose the confusion is endemic; as everyone thinks about the project costs in terms of per person and this is considered by assumption to be one smart card per person, but the cost per person is not the single 50c per actual smart card. Smart cards are a lot like Christmas, it's not the gift, but the act of giving that makes it special. The real constraint is that you're unlikely to have more than one card reader in a machine, so multifunction cards provide the opportunity to run multiple applications without switching cards in and out, but that only works if the application vendors cooperate. For instance, you may have some encrypted session application that needs to have your card stay in the machine during the session (e.g. VOIP, or secure login, SSH-like things, remote file system access), and you may want to pay for something using your bank smartcard during the session. That's not likely to work out, because the secure session software vendors are unlikely to have a relationship with your bank that lets both of them trust each other with their information, compared to the simpliciy of having multiple cards. For example, yes. So it all comes down to whether you can afford to role out the hardware to all the vendors, and all the associated nodes. At this point, the penny drops, and smart cards start looking very expensive. Hence, to date, only single-purpose projects have succeeded - ones where the economics where clearly based on narrowly focused, single activities: phones, transit systems, etc, and they justified themselves on those activities, alone, without relying on the economics of unmeasurable and unmeetable hyperbole. iang PS: all those Europeans with all those smart cards in their pockets - ask them how many times they use the smart card features! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: IP2Location.com Releases Database to Identify IP's Geography
The IP2Location(TM) database contains more than 2.5 million records for all IP addresses. It has over 95 percent matching accuracy at the country level. Available at only US$499 per year, the database is available via download with free twelve monthly updates. And since the charge is per-server, not per-query, you could easily set up an international free service on a big piece of iron. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
