August 2002 - cypherpunks-legacy

RE: trade-offs of secure programming with Palladium (Re: Palladiu m: technical limits and implications)
by Trei, Peter 15 Aug '02

15 Aug '02

> Russell Nelson[SMTP:nelson@crynwr.com] writes: > > You're wearing your programmer's hat when you say that. But the > problem isn't programming, but is instead economic. Switch hats. The > changes that you list above may or may not offer some security > advantages. Who cares? What really matters is whether they increase > the cost of copying. I say that the answer is no, for a very simple > reason: breaking into your own computer is a "victimless" crime. > > In a crime there are at least two parties: the victim and the > perpetrator. What makes the so-called victimless crime unique is that > the victim is not present for the perpetration of the crime. In such > a crime, all of the perpetrators have reason to keep silent about the > comission of the crime. So it will be with people breaking into their > own TCPA-protected computer and application. Nobody with evidence of > the crime is interested in reporting the crime, nor in stopping > further crimes. > [...] Russ: Take off your economic hat, and try on a law-enforcement one. With DMCA, etal, the tools to get around TCPA's taking of your right to use your property as you please have been criminalized. (Don't argue that TCPA will always be voluntary. I don't beleive that). I have little patience with arguments which say 'Yeah, they can make X against the law, but clever people like me can always get around it, and won't get caught, so I don't care.' Maybe you can, some of the time, but that's not the point. Most people won't, either because it's too hard, they don't know what they've lost, or because of a misplaced respect for the whims of The Men with Guns. This is not a Good Thing. A freedom to skulk in the shadows, hoping not to be noticed, is not the legacy I wish to leave behind. Peter Trei --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

Fw: Bay Area SDF SECURITY EVENTS ANNOUNCEMENT
by Bill Stewart 15 Aug '02

15 Aug '02

We've missed the first Nightwatch\\\\\\\\ SF Bay InfraGard meeting :-) But there are other things here as well. ---------- Forwarded Message ----------- August SDF Security SIG Meeting... A DOUBLE HEADER Don't Miss This Month's SIG Meeting -You Will Get A Ton of Voluble Information On Two Important Security Topics Martin Roesch, the Co-Author of Snort, the industry's most widely deployed Intrusion Detection System (IDS) & Voice Authentication - Biometric Security With Just a Microphone Wednesday, August 21 2002 @ 6:30pm Details: http://www.sdforum.org/p/calEvent.asp?CID=858&mo=8&yr=2002 +++++++++++++ SF Bay InfraGard Chapter - Summer/Quarterly Meeting Thursday / August 15, 2002 / 9AM - Noon Networking & Registration starts at 8:15AM Location: Cooley Godward, LLC 3175 Hanover Street, Palo Alto, CA 94306 NO CHARGE, BUT RSVP TO FBI Special Agent Mary Kimura, mkimura(a)fbi.gov More Info: http://sfbay-infragard.org/ SDForum SIG Chairs Ira and Ames are members of Infragard and we plan to attend this event ++++++++++++++ Party with EFF a the DNA Lounge - Live Music and Celebrity Boxing! CAFE 2002 - a Benefit for EFF's Campaign for Audiovisual Free _Expression Thursday, August 22nd, 2002/ 9pm - afterhours The night features world-class DJs, live acts, and producers from all parts of the fast-growing electronic music community and a special treat: celebrity boxing with Wil Wheaton and Barney! Wil Wheaton, of Star Trek: The Next Generation and Stand By Me fame, will take on Barney in a celebrity boxing matchup for the history books. All proceeds from the event will directly benefit EFF's CAFE project, helping to preserve your freedom to express yourself in innovative ways. Wheaton will be speaking at the event, along with EFF Co-Founder John Perry Barlow, EFF Executive Director Shari Steele and Heather Gold, comedian and Subvert.com host. More Info: http://www.eff.org/cafe ++++++++ SDForum Security SIG is sponsored by Kaspersky Lab(http://kaspersky-cs.com), Sierra Ventures (http://www.sierraven.com) and our NEW SPONSOR - Privastaff (http://www.privastaff.com) SDForum Security SIG is hosted By Ames Cornish (http://www.montebellopartners.com) and Ira Victor (http://www.iravictor.net) ------- End of Forwarded Message ------- www.SallyRichards.com FutureNet (2002) Inside Business Incubators & Corporate Ventures (2001) Dot-com Success! Surviving the Fallout & Consolidation (2000) Sand Dreams & Silicon Orchards (2000) Cofounder WiWoWo (Wild Women of Wonder): http://www.fortune.com/indexw.jhtml?channel=artcol.jhtml&doc_id=206092 Recent BBC interviews: http://www.bbc.co.uk/radio4/science/siliconvalley.shtml "It is better to die standing, than to live on your knees" -Dolores Ibarruri, Spanish Revolutionary

1 0

Re: 2seks
by Senada Gemici 15 Aug '02

15 Aug '02

Hic bir yerde bulup izleyemeyeceginiz icerigi size http://www.2seks.com sunuyor. TURK VE AVRUPALI AMATOR KIZLAR BULGAR KIZLARI ROMEN HATUNLAR TURK TECAVUZ FILMLERI KIZLAR YURDU ALMANYA'NIN SAPIK HATUNLARI OTELDEKI GIZLI KAMERALAR VE DAHASI... Hepsi orjinal ve kaliteli kayitlar. Hemen giris yapin ve tadini cikartin http://www.2seks.com

1 0

Bluetooth security,"Is it safe?"
by Matthew X 15 Aug '02

15 Aug '02

http://www.newsfactor.com/perl/story/19028.html Token encryption. If a user wearing the system's security token walks away from his or her laptop, the system senses it and begins securing the computer by encrypting all data. If the user then returns within range, the computer begins unlocking data so work can resume. "Its safe,its very safe!" MM.

1 0

Re: Overcoming the potential downside of TCPA
by AARG! Anonymous 15 Aug '02

15 Aug '02

Joe Ashwood writes: > Actually that does nothing to stop it. Because of the construction of TCPA, > the private keys are registered _after_ the owner receives the computer, > this is the window of opportunity against that as well. Actually, this is not true for the endoresement key, PUBEK/PRIVEK, which is the "main" TPM key, the one which gets certified by the "TPM Entity". That key is generated only once on a TPM, before ownership, and must exist before anyone can take ownership. For reference, see section 9.2, "The first call to TPM_CreateEndorsementKeyPair generates the endorsement key pair. After a successful completion of TPM_CreateEndorsementKeyPair all subsequent calls return TCPA_FAIL." Also section 9.2.1 shows that no ownership proof is necessary for this step, which is because there is no owner at that time. Then look at section 5.11.1, on taking ownership: "user must encrypt the values using the PUBEK." So the PUBEK must exist before anyone can take ownership. > The worst case for > cost of this is to purchase an additional motherboard (IIRC Fry's has them > as low as $50), giving the ability to present a purchase. The > virtual-private key is then created, and registered using the credentials > borrowed from the second motherboard. Since TCPA doesn't allow for direct > remote queries against the hardware, the virtual system will actually have > first shot at the incoming data. That's the worst case. I don't quite follow what you are proposing here, but by the time you purchase a board with a TPM chip on it, it will have already generated its PUBEK and had it certified. So you should not be able to transfer a credential of this type from one board to another one. > The expected case; > you pay a small registration fee claiming that you "accidentally" wiped your > TCPA. The best case, you claim you "accidentally" wiped your TCPA, they > charge you nothing to remove the record of your old TCPA, and replace it > with your new (virtualized) TCPA. So at worst this will cost $50. Once > you've got a virtual setup, that virtual setup (with all its associated > purchased rights) can be replicated across an unlimited number of computers. > > The important part for this, is that TCPA has no key until it has an owner, > and the owner can wipe the TCPA at any time. From what I can tell this was > designed for resale of components, but is perfectly suitable as a point of > attack. Actually I don't see a function that will let the owner wipe the PUBEK. He can wipe the rest of the TPM but that field appears to be set once, retained forever. For example, section 8.10: "Clear is the process of returning the TPM to factory defaults." But a couple of paragraphs later: "All TPM volatile and non-volatile data is set to default value except the endorsement key pair." So I don't think your fraud will work. Users will not wipe their endorsement keys, accidentally or otherwise. If a chip is badly enough damaged that the PUBEK is lost, you will need a hardware replacement, as I read the spec. Keep in mind that I only started learning this stuff a few weeks ago, so I am not an expert, but this is how it looks to me.

1 0

CT-RSA 2003 -- preliminary call for papers
by Trei, Peter 15 Aug '02

15 Aug '02

[From sci.crypt -pt]

1 0

Re: A faster way to factor prime numbers found?
by Tim May 15 Aug '02

15 Aug '02

On Tuesday, August 13, 2002, at 03:07 PM, Gary Jeffers wrote: > A faster way to factor prime numbers found? > Faster even than the usual algorithm?: The factors of a prime number are 1 and the number itself. --Tim May "That the said Constitution shall never be construed to authorize Congress to infringe the just liberty of the press or the rights of conscience; or to prevent the people of the United States who are peaceable citizens from keeping their own arms." --Samuel Adams

1 0

This Weeks Special Offers!
by Computer Developments UK 15 Aug '02

15 Aug '02

1 0

TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
by Adam Back 15 Aug '02

15 Aug '02

[resend via different node: cypherpunks(a)lne.com seems to be dead -- primary MX refusing connections] Phew... the document is certainly tortuous, and has a large number of similarly and confusingly named credentials, certificates and keys, however from what I can tell this is what is going on: Summary: I think the endorsement key and it's hardware manufacturers certificate is generated at manufacture and is not allowed to be changed. Changing ownership only means (typically) deleting old identities and creating new ones. The longer version... - endorsement key generation and certification - There is one endorsement key per TPM which is created and certified during manufacture. The creation and certification process is 1) create endorsement key pair, 2) export public key endorsement key, 3) hardware manufacturer signs endorsement public key to create an endorsement certificate (to certify that that endorsement public key belongs to this TPM), 4) the certificate is stored in the TPM (for later use in communications with the privacy CA.) - ownership - Then there is the concept of ownership. The spec says the TPM MUST ship with no Owner installed. The owner when he wishes to claim ownership choose a authentication token which is sent into the TPM encrypted with the endorsement key. (They give the example of the authentication token being the hash of a password). Physical presence tests apply to claiming ownership (eg think BIOS POST with no networking enabled, or physical pin on motherboard like BIOS flash enable). The authentication token and ownership can be changed. The TPM can be reset back to a state with no current owner. BUT _at no point_ does the TPM endorsement private key leave the TPM. The TPM_CreateEndorsementKeyPair function is allowed to be called once (during manufacture) and is thereafter disabled. - identity keys - Then there is the concept of identity keys. The current owner can create and delete identities, which can be anonymous or pseudonymous. Presumably the owner would delete all identity keys before giving the TPM to a new owner. The identity public key is certified by the privacy CA. - privacy ca - The privacy CA accepts identity key certification requests which contain a) identity public key b) a proof of possession (PoP) of identity private key (signature on challenge), c) the hardware manufacturers endorsement certificate containing the TPM's endorsement public key. The privacy CA checks whether the endorsement certificate is signed by a hardware manufacturer it trusts. The privacy CA sends in response an identity certificate encrypted with the TPM's endorsement public key. The TPM decrypts the encrypted identity certifate with the endorsement private key. - remote attestation - The owner uses the identity keys in the remote attestation functions. Note that the identity private keys are also generated on the TPM, the private key also never leaves the TPM. The identity private key is certified by the privacy CA as having been requested by a certified endorsement key. The last two paragraphs imply something else interesting: the privacy CA can collude with anyone to create a virtualized environment. (This is because the TPM endorsement key is never directly used in remote attestation for privacy reasons.) All that is required to virtualize a TPM is an attestation from the privacy CA in creating an identity certificate. So there are in fact three avenues for FBI et al to go about obtaining covert access to the closed space formed by TCPA applications: (A) get one of the hardware manufacturers to sign an endorsement key generated outside a TPM (or get the endorsement CA's private key), or (B) get a widely used and accepted privacy CA to overlook it's policy of demanding a hardware manufacturer CA endorsed endorsement public key and sign an identity public key created outside of a TPM (or get the privacy CA's private key). (C) create their own privacy CA and persuade an internet server they wish to investigate the users of to accept it. Create themselves a virtualized client using their own privacy CA, look inside. I think to combat problem C) as a user of a service you'd want the remote attestation of software state to auditably include it's accepted privacy CA database to see if there are any strange "Privacy CAs" on there. I think you could set up and use your own privacy CA, but you can be sure the RIAA/MPAA will never trust your CA. A bit like self-signing SSL site keys. If you and your friends add your CA to their trusted root CA database it'll work. In this case however people have to trust your home-brew privacy CA not to issue identity certificates without having seen a valid hardware-endorsement key if they care about preventing virtualization for the privacy or security of some network application. Also, they seem to take explicit steps to prevent you getting multiple privacy CA certificates on the same identity key. (I'm not sure why.) It seems like a bad thing as it forces you to trust just one CA, it prevents web of trust which could reduce your chances of getting caught in attack scenarios B) and C) by demanding multiple certificates. This section from the spec on trusting the privacy CA is interesting also: section 8.3.1 p 195 | A TPM identity key may be used to certify non-migratable keys but is | not permitted to certify migratory keys. As such, it allows the TPM | to make the statement this key is held in a TCPA-shielded location, | and it will never be revealed. For this statement to have veracity, | the Challenger must trust the policies used by the Privacy CA that | issued the identity and the maintenance policy of the TPM | manufacturer. (not sure what the maintenance policy of the TPM is or what it has to do with trusting privacy CAs -- it is not otherwise discussed). also the text on p268 relates to trusting the privacy CA. Below is some text from the spec which tends to confirm the above. (Anonymous may have some comments as he seemed to have read the TCPA spec in more detail than I have.) Here is an indicative quote from the spec: informative comment: | section 5.11 TPM Ownership p 133 | | "The function to insert the owner must provide the following: | | Confidentiality. The shared secret (or authorization data) must remain | confidential to all eavesdroppers that intercept any of the | messages. The confidentiality comes from encrypting the shared secret | using the TPM PUBEK. The Owner trusts that only the TPM has the PRIVEK | that can decrypt the shared secret. normative text: | The TPM MUST ship with no Owner installed. The TPM MUST use the | ownership-control protocol. Anyway Occam's razor suggests that the intent is: 1. the TPM endorsement private key never leaves the TPM 2. the identity private keys never leave the TPM 3. the privacy CA will never issue identity private keys unless the request is made in relation to a manufacturer certified endorsement public key. Note: The endorsement key has key usage restrictions and is marked as encrypt only, so the assurance the privacy CA gets is not that it receives a identity certificate request signed by the endorsement private key, but rather that the issued certificate is encrypted with the endorsement public key and so could only be decrypted by the TPM which contains the corresponding private endorsement key. (I suppose the motivation might have been that then the privacy CA couldn't prove to third parties that your endorsement key and identity key are bound together.) Adam -- http://www.cypherspace.org/adam/ On Wed, Aug 14, 2002 at 03:10:44PM -0700, Joseph Ashwood wrote: > ----- Original Message ----- > From: "Ben Laurie" <ben(a)algroup.co.uk> > > Joseph Ashwood wrote: > > > There is nothing stopping a virtualized version being created. > > > What prevents this from being useful is the lack of an appropriate > > certificate for the private key in the TPM. > > Actually that does nothing to stop it. Because of the construction of TCPA, > the private keys are registered _after_ the owner receives the computer, > this is the window of opportunity against that as well. The worst case for > cost of this is to purchase an additional motherboard (IIRC Fry's has them > as low as $50), giving the ability to present a purchase. The > virtual-private key is then created, and registered using the credentials > borrowed from the second motherboard. Since TCPA doesn't allow for direct > remote queries against the hardware, the virtual system will actually have > first shot at the incoming data. That's the worst case. The expected case; > you pay a small registration fee claiming that you "accidentally" wiped your > TCPA. The best case, you claim you "accidentally" wiped your TCPA, they > charge you nothing to remove the record of your old TCPA, and replace it > with your new (virtualized) TCPA. So at worst this will cost $50. Once > you've got a virtual setup, that virtual setup (with all its associated > purchased rights) can be replicated across an unlimited number of computers. > > The important part for this, is that TCPA has no key until it has an owner, > and the owner can wipe the TCPA at any time. From what I can tell this was > designed for resale of components, but is perfectly suitable as a point of > attack. > Joe > > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

Consider this if you will.
by Matthew X 15 Aug '02

15 Aug '02

Consider this: An inarticulate, politically inexperienced man with family links to a previous national regime comes to provincial leadership. Subsequently he gains the highest national office without winning the popular vote. The election in which he was declared the victor is considered compromised by his brother's province. He appoints a chief law enforcement officer who has repeatedly called for constitutional revisions. Regulatory agencies are filled with those previously regulated. Soldiers patrol transportation centers. International treaties are abrogated. International legal organizations are shunned. Roles of police and military are blurred. Law enforcement agencies are centralized. Individual civil rights are reduced. A "shadow" government is created. Domestic surveillance is increased. People are encouraged to spy on each other. Military budgets are increased. The military establishes a disinformation program. Media access to government is limited. Consultations with the legislative branch decline. Connections to corrupt corporate sponsors are disavowed. Efforts to further plunder natural resources for profit are initiated. Access to past administrations' documents is limited. A war mentality is established with imprecise enemies. Nebulous fear- inducing alerts are periodically released. National level profiling is introduced. People are imprisoned without public charges and unknown others are "disappeared." http://www.indymedia.org/front.php3?article_id=198145&group=webcast Don't mention the war.

1 0