Re: Retailers try to push data responsibilities back to banks
some number of other recent notes on the subject:
Customer Service: Consumer Confidence at Stake in Retail, Credit Card
Industry Clash
http://www.ecommercetimes.com/story/59670.html
Retailer PCI Rebellion: 'No More Storing Credit Card Numbers'
http://www.darkreading.com/document.asp?doc_id=135602
Retailers Fighting To No Longer Store Credit Data
http://it.slashdot.org/it/07/10/05/192250.shtml
Retail group takes a swipe at PCI
http://www.infoworld.com/article/07/10/05/Retail-group-takes-a-swipe-at-PCI_1.html
Retailers Challenge the Networks’ Card-Data Storage Requirements
http://www.digitaltransactions.net/newsstory.cfm?newsid=1536
NRF to Credit Card Companies: Stop Forcing Retailers to Store Credit Card Data
http://www.nrf.com/modules.php?name=News&op=viewlive&sp_id=380
Retail group takes a swipe at PCI, puts card companies 'on notice'
http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=security&articleId=9040958&taxonomyId=17
Rethinking the Assumptions Behind PCI-DSS
http://www.paymentsnews.com/2007/10/rethinking-the-.html
PCI Is Here: Keeping the barbarians outside the cyber gates
http://www.practicalecommerce.com/articles/580/Caveat-Vendor-PCI-Is-Here/
Retailers, Credit Card Industry Clash
http://www.physorg.com/news110781861.html
we had been called in to consult with this small client/server startup that
wanted to do payment transactions. this required some amount of translating
technology into business critical data processing ... which has somewhat
come to be referred to as "electronic commerce". This including technology
invention that they called SSL ... and among other things we had to do
some detailed audits of these supporting infrastructures that were calling
themselves certification authorities ... various past posts on the subject
http://www.garlic.com/~lynn/subnetwork.html#gateway
in the mid-90s we got involved in the x9a10 financial standard working group
that had been given the requirement to preserve the integrity of the
financial infrastructure for all retail payments. we drew on our experience
having previously done "electronic commerce" as well as some detailed
vulnerability studies and threat models. having been given the requirement
for all retail payments ... we had to look at a standard that was lightweight
enuf that could be easily deployed in both point-of-sale as well as internet
environments ... and provide end-to-end security and integrity with
countermeasures
for both "data-in-flight" vulnerabilities (aka transaction transmission)
as well as "data-at-rest" vulnerabilities (aka transaction logs and databases).
part of the issue was some studies that claimed as much as 70 percent
of ("data-in-flight" and "data-at-rest") compromises involved "insiders"
(aka countermeasures had to recognize that majority of compromises
possibly involved individuals with legitimate access to the information).
the resulting financial standard was x9.59
http://www.garlic.com/~lynn/x959.html#x959
the x9.59 approach was to eliminate fraudulent transactions resulting
evesdropping and data breach compromises ... aka it didn't eliminate
evesdropping and data breach compromises ... but it eliminated the
ability of attackers (insiders or outsiders) to use the information
that they had obtained for purposes of doing fraudulent transactions.
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Undocumented Bypass in PGP Whole Disk Encryption
On Thu, Oct 04, 2007 at 02:37:21PM -0500, [EMAIL PROTECTED] wrote: > http://it.slashdot.org/article.pl?sid=07/10/04/1639224&from=rss > > Interesting quote: > > Jon Callas, CTO and CSO of PGP Corp., responded that this [previously > undocumented] feature was required by unnamed customers and that > competing products have similar functionality. The article is sensational nonsense. The quote is right on the money, businesses require disk encryption companies to support one time unprotected reboot (enabled securely before reboot) to support automated rebuilds. Without this requirement, the Windows desktop support teams refuse to field the products. The problem is not interesting, the feature cannot be enabled after the fact. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Retailers try to push data responsibilities back to banks
On Thu, Oct 04, 2007 at 06:48:49PM -0400, Leichter, Jerry wrote: > Prat Moghe, founder and CTO of Tizor Systems Inc., a Maynard, > Mass.-based security firm, called the NRF's demand political posturing > and said it would do little to improve retail security anytime soon. > > "I think a lot of this is about moving culpability back to the credit > card companies and saying don't make this my problem alone," Moghe > said. "They seem to have realized that going on the defense as an > industry doesn't help. There is just more and more they have to do." Amazingly, Tizor Systems does PCI reviews (actually they entirely seem to do C&A work), and I'm sure Prat would prefer to see the PCI gravy train stay around. (I don't know the current state of the industry, but when I was working in a consulting group 2004-2005, PCI reviews were our most profitable engagement type by a large margin - and non-technical enough that you can put a person with a few months of security training on them and they'll do fine). -Jack - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Seagate announces hardware FDE for laptop and desktop machines
> I think the really interesting question is what happens when you lose > a FDE-ed hard drive. Do you still need to publish the incident and > contact potentially affected individuals? If the answer is "no", I'm > sure this technology will be quickly adopted, independently of its > actual implementation. California Senate Bill CA1386 provides a "Get Out of Jail Free" Card if you are using "reasonable" means to protect the confidentiality of data. However you still have to proof it saqib http://security-basics.blogspot.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Retailers try to push data responsibilities back to banks
Retail group takes a swipe at PCI, puts card companies 'on notice' Jaikumar Vijayan October 04, 2007 (Computerworld) Simmering discontent within the retail industry over the payment card industry (PCI) data security standards erupted into the open this week with the National Retail Federation (NRF) asking credit card companies to stop forcing retailers to store payment card data. In a tersely worded letter to the PCI Security Standards Council, which oversees implementation of the standard, NRF CIO David Hogan asked credit card companies to stop making retailers "jump through hoops to create an impenetrable fortress" to protect card data. Instead, "retailers want to eliminate the incentive for hackers to break into their systems in the first place." "With this letter, we are officially putting the credit card industry on notice," Hogan said in a statement. The NRF, a trade association whose membership includes most of the major retailers in the U.S., is the national voice for about 1.4 million U.S retail establishments. In an interview with Computerworld this morning, Hogan said the letter was provoked by a "lot of frustration" in the industry about PCI guidelines and the deadlines associated with implementing them. If the goal of PCI is to protect credit card data, the easiest and most common sense approach is to stop requiring merchants to store the data in the first place, he said. PCI is a data security standard mandated by Visa International Inc., MasterCard International Inc., American Express Co., Discover and the Japan Credit Bureau. It requires companies to implement a set of prescribed security controls for protecting cardholder data. Though the requirements went into affect more than two years ago, a large number of big retailers are still noncompliant because of a variety of issues that include legacy system challenges, rules interpretation issues and continuously evolving guidelines. According to Hogan, credit card companies require retailers and others accepting payment card transactions to store certain card data sometimes for up to 18 months so that it can be retrieved in the event of chargebacks and other disputes. But rather than have thousands of retailers store the data, credit card companies and their banks should do so, Hogan said. Retailers only need an authorization code provided at the time of a sale to validate a charge, and a receipt with truncated credit card information to handle returns and refunds. If that were done, he said, most retailers probably wouldn't store any cardholder data. According to Hogan, under the current process, credit card companies and their banks already have the information needed for retrieval purposes and it should be their responsibility to store and protect the data. "It is a very fundamental shift. But if you think about it, it is a very common-sense approach." PCI mandates are challenging retailers to build fortresses around credit card data, he said. "We build these higher walls and the hackers bring in taller ladders and this kind of keeps scaling up all the time." Gartner Inc. analyst Avivah Litan said that the NRF letter makes a "sound argument. "It's totally reasonable to tell the banking system and payment system that 'we don't want to store this data anymore,'" she said. "If they aren't storing this data, many of these [PCI] requirements go away and the scope of the compliance effort is much more restricted. In an e-mailed comment, Bob Russo, general manager of the PCI security standards council, said the body received the NRF letter yesterday and will respond after reviewing it further. "However, it must be recognized that the payment brands -- and not the Council -- operate the systems underlying the payments process, as well as the compliance programs. Because of this, Mr. Hogan should be directing his concerns to those individual brands." Jon Hurst, president of the Retailers Association of Massachusetts, backed the NRF's position. With all of the attention paid to PCI, what's gone unnoticed is the fact that card companies themselves require certain amounts of data to be stored because of disputed transactions, he said. If not for that requirement, many retailers -- especially the large ones -- would probably not keep data and therefore wouldn't be pressed to secure it, he said. Prat Moghe, founder and CTO of Tizor Systems Inc., a Maynard, Mass.-based security firm, called the NRF's demand political posturing and said it would do little to improve retail security anytime soon. "I think a lot of this is about moving culpability back to the credit card companies and saying don't make this my problem alone," Moghe said. "They seem to have realized that going on the defense as an industry doesn't help. There is just more and more they have to do." By speaking out aggressively at a time when retail industry information security practices are under scrutiny by consumers and lawmakers, the NRF is hoping to spread the liability
ECC vs. D/H or RSA
Does anyone have information on: 1) The ECAES weakness that led to ECIES 2) Any known weaknesses of ECIES 3) Relative performance figures between ECC routines like ECIES and D/H (or possibly RSA, though IES is based on EC-DH) I can generate the last if these figures are not available. BTW, I noticed that the latest OpenSSL has some EC functions, including EC-DH IIRC. It does not have ECAES or ECIES though. References: http://en.wikipedia.org/wiki/ECIES http://www.secg.org/download/aid-385/sec1_final.pdf -- http://www.subspacefield.org/~travis/> Tat Tvam Asi For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpvAz1RvHImk.pgp Description: PGP signature
Undocumented Bypass in PGP Whole Disk Encryption
http://it.slashdot.org/article.pl?sid=07/10/04/1639224&from=rss Interesting quote: Jon Callas, CTO and CSO of PGP Corp., responded that this [previously undocumented] feature was required by unnamed customers and that competing products have similar functionality. -- http://www.subspacefield.org/~travis/> Tat Tvam Asi For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpUavsYRK20D.pgp Description: PGP signature
Re: Bid on a SnakeOil Crypto Algorithm Patent
On 10/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On 10/3/07, Saqib Ali <[EMAIL PROTECTED]> wrote: > [SNIP] > or both private keys but that never seems to get mentioned > I take it back, there is only one private key but math makes multiple temporary public keys out of it. -Michael - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Bid on a SnakeOil Crypto Algorithm Patent
On 10/3/07, Saqib Ali <[EMAIL PROTECTED]> wrote: > http://www.freepatentauction.com/patent.php?nb=950 > > Snake Oil Keywords: > 1) Breach-proof Encryption, > 2) landmark invention in Cryptography and Information Security > The basic details seem to be that data in flight gets protected by splitting the message, encrypting each half protected by a different RSA key, and sending each half along a different route using source routing. This means that if an attacker gets the stream on one route, they cannot get the message even if they have one private key (or both private keys but that never seems to get mentioned in the docs). This is where "breach proof" comes from. -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Seagate announces hardware FDE for laptop and desktop machines
* Ivan Krstić: > On Oct 3, 2007, at 4:39 AM, Florian Weimer wrote: >> But this exhibits an issue with disk-based encryption: you can't >> really know what they are doing, and if they are doing it right. >> (Given countless examples of badly-deployed cryptography, this isn't >> just paranoia, but a real concern.) > > Precisely. If you're keeping secrets from your nosy siblings and > coworkers, hardware FDE is more than adequate. If you have reason to > believe someone skilled and resourceful might really want your data, > you almost certainly have no business using a blackbox encryption > system operating in a way that's not publicly documented -- even if > the system is buzzword-compliant -- and implemented by a company > (hard disk vendor) where crypto is about as far from their core > competency as you can get. I think the really interesting question is what happens when you lose a FDE-ed hard drive. Do you still need to publish the incident and contact potentially affected individuals? If the answer is "no", I'm sure this technology will be quickly adopted, independently of its actual implementation. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: fyi: Storm Worm botnet numbers, via Microsoft
[EMAIL PROTECTED] writes: >food for consideration. yes, #s are from MSFT as he notes, but are the only >ones we have presently wrt actual Storm extent, yes? If not, pls post >pointers... I have two problems with this report. Firstly, I don't think this is a very representative sampling technique compared to the estimates from security companies. If you look at the sample that's being used, "Windows machines that have automatic updates turned on", then the typical machine is going to be configured with something like Windows XP SP2 with all available hotfixes and updates applied, in other words the very systems that are (one would hope :-) the *least* likely to be affected by malware. If you take the rule-of- thumb estimate that's sometimes used on MSDN blogs of 1B Windows machines out there then 2.6M machines is < 0.3% of that total. Now this in itself wouldn't be so bad if it was an unbiased sample, but in fact it's probably a rather non-representative 0.3%. Although some of the numbers from security companies for infections may be just guesswork, they also use broad sampling across all Windows machines (not just ones with Windows Defender), honeypots, monitoring of botnet traffic patterns, and other methods as well. So while it's valid to say that this provides data for Storm on fully patched, up-to-date machines running Windows Defender, I don't think this generalises for all Windows machines. Secondly, the text completely contradicts the figures given. If the figures really are accurate and not a typo, then 274K machines infected out of 2.6M puts Storm on 10% of Windows PCs, which would make the worldwide infection rate 100M systems, or ten times larger than the previous worst-possible case estimate. Storm may be big, but it's not *that* big. I think there's something wrong with the figures. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Bid on a SnakeOil Crypto Algorithm Patent
Saqib Ali wrote: http://www.freepatentauction.com/patent.php?nb=950 googlepatent gives me: http://www.google.com/patents?id=HaN6EBAJ&dq=7,088,821 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Seagate announces hardware FDE for laptop and desktop machines
On Oct 3, 2007, at 4:39 AM, Florian Weimer wrote: But this exhibits an issue with disk-based encryption: you can't really know what they are doing, and if they are doing it right. (Given countless examples of badly-deployed cryptography, this isn't just paranoia, but a real concern.) Precisely. If you're keeping secrets from your nosy siblings and coworkers, hardware FDE is more than adequate. If you have reason to believe someone skilled and resourceful might really want your data, you almost certainly have no business using a blackbox encryption system operating in a way that's not publicly documented -- even if the system is buzzword-compliant -- and implemented by a company (hard disk vendor) where crypto is about as far from their core competency as you can get. -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
