Re: Financial identity is *dangerous*? (was re: Fake companies, real money)
At 9:29 AM -0700 10/28/04, James A. Donald wrote: Is there a phone that is programmable enough to store secrets on and sign and decrypt stuff? I think we're getting there. We're going to need a, heh, killer ap, for it, of course. :-) Cheers, RAH -- - 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: MCI set to offer secure two-way messaging with strong encryption
At 01:16 PM 10/28/04, you wrote: MCI Inc. will offer secure two-way messaging through its SkyTel Communications subsidiary next month, encrypting wireless text with the Advanced Encryption Algorithm. This service has been available to U.S. Government customers for at least seven years, albeit not always with AES. SkyTel was keenly aware that capturing and decoding their paging traffic was well within the means of even casual hobbyists. Note that they don't say it's end to end encryption: Messages are encrypted between the device and an encryption server at SkyTel's secure network operations center. And presumably wiretappable there. Yep. --Dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[ISN] Secret Service busts online organized crime ring
--- begin forwarded text Date: Fri, 29 Oct 2004 03:31:38 -0500 (CDT) From: InfoSec News [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [ISN] Secret Service busts online organized crime ring Reply-To: [EMAIL PROTECTED] List-Id: InfoSec News isn.attrition.org List-Archive: http://www.attrition.org/pipermail/isn List-Post: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: http://www.attrition.org/mailman/listinfo/isn, mailto:[EMAIL PROTECTED] Sender: [EMAIL PROTECTED] http://www.computerworld.com/securitytopics/security/story/0,10801,97017,00.html By Dan Verton OCTOBER 28, 2004 COMPUTERWORLD In what it called an Information Age undercover investigation, the U.S. Secret Service today announced that it has arrested 28 people from eight U.S. states and six countries allegedly involved in a global organized cybercrime ring. Charges filed against the suspects include identity theft, computer fraud, credit card fraud and conspiracy. The investigation, code-named Operation Firewall, resulted in what the Secret Service described as a significant disruption of organized criminal activity online that was targeting the financial infrastructure of the U.S. The suspects are alleged to have collectively trafficked in at least 1.7 million stolen credit card numbers. Financial institutions have estimated their losses associated with the suspects targeted by the investigation to be more than $4.3 million. Led by the Secret Service Newark Field Office, investigators from nearly 30 domestic and foreign Secret Service offices and their global law enforcement counterparts have prevented potentially hundreds of millions of dollars in loss to the financial and hi-tech communities, Secret Service Director W. Ralph Basham said in a statement. These suspects targeted the personal and financial information of ordinary citizens, as well as the confidential and proprietary information of companies engaged in e-commerce. Operation Firewall began in July 2003 and quickly evolved into a transnational investigation of global credit card fraud and online identity theft. The underground criminal groups have been identified as Shadowcrew, Carderplanet and Darkprofits. The organizations operated Web sites used to traffic counterfeit credit cards and false identification information and documents. The groups allegedly used the sites to share information on how to commit fraud and sold the stolen information and the tools needed to commit such crimes. International law enforcement organizations that took part in the investigation and arrests included the U.K.'s National Hi-Tech Crimes Unit, the Vancouver Police Department's Financial Crimes Section, the Royal Canadian Mounted Police and Europol. Officials in Bulgaria, Belarus, Poland, Sweden, the Netherlands and Ukraine also were involved. _ Open Source Vulnerability Database (OSVDB) Everything is Vulnerable - http://www.osvdb.org/ --- 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' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Financial identity is *dangerous*? (was re: Fake companies, real money)
James A. Donald wrote: R.A. Hettinga wrote: [The mobile phone is] certainly getting to be like Chaum's ideal crypto device. You own it, it has its own I/O, and it never leaves your sight. Is there a phone that is programmable enough to store secrets on and sign and decrypt stuff? I've been programming phones and PDAs for several years. They are certainly powerful enough for symmetric operations. Some at the higher end can to public key operations at a reasonable speed. The lower end ones can't. Try taking a look at the new Treos, the newer PocketPC devices, and phones such as the Motorola A760. The ideal crypto device would be programmed by burning new proms, thus enabling easy reprogramming, while making it resistant to trojans and viruses. Some of the devices partition their storage, with portions that are easily modified, and portions which are more secure. The carriers generally want to prevent users from modifying the SW in ways which could enable fraud or damage the network, yet allow downloads of games, apps, etc. Peter - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Financial identity is *dangerous*? (was re: Fake companies, real money)
At 10:29 AM 10/28/2004, James A. Donald wrote: Is there a phone that is programmable enough to store secrets on and sign and decrypt stuff? The ideal crypto device would be programmed by burning new proms, thus enabling easy reprogramming, while making it resistant to trojans and viruses. there are a couple different trust relationships ... the issue of the user trusting the keyboard/terminal ... and the issue of the relying party trusting the keyboard/terminal. The FINREAD terminal ... misc. (EU) finread references: http://www.garlic.com/~lynn/subpubkey.html#finread supposedly is certified as an stand-alone external keypad and display that can't (very difficult) in being hacked. the financial scenario is that the display can be trusted to display the amount being approved the user puts in his card and enters their pin/password. The pin-pad is certified as not being subject to virus keyloggers (that you might find if a PC keyboard was being used). For the relying party (say an online financial institution) ... the user putting their card into the reader ... and the card generating some unique value ... would indicate to the relying party something you have authentication. The user entering a PIN can both indicate something you know authentication as well as implying that the user aggrees/approves with the value in the display. Note that the implied agreement/approval ... in not just dependent on the user entering the PIN ... but also on the certification of the terminal ... that the terminal doesn't accept the PIN until after the certified terminal displays the correct value (i.e. there is a certified business process sequence). The entering of the PIN can also involving transmitting some form of the PIN to the relying party ... and/or the PIN is passed to the smartcard/chip ... and the chip is known to only operate in the appropriate manner when the correct PIN is entered. In this later case, the relying party doesn't actually have knowledge of the something you know authentication but the relying party can infer it based on knowing the certified business process operation of all of the components. Lets say the unique value provided by the smartcard is some form of digital signature ... and the relying party infers from the correct digitial signature something you have authentication. There is still the trust issue between the relying party and the terminal used by the user which may also require that the (certified eu finread) terminal also performs a digital signature in order for the relying party to be able to trust that it really was a terminal of specific characteristics ... as opposed to some counterfeit or lower-trusted terminal. There is still the issue of the user trusting such a terminal. If the terminal belongs to the user in the user physical home space then there isn't as much of a trust issue regarding the user trusting the terminal. The problem arises for the user if they are faced with using a terminal in some random, unsecured location some place in the world. Even in the situation where a relying party receives a valid transaction with a valid digital signature from a certified, known finread terminal ... there are still a number of MITM attacks on finread terminals that might be located in unsecured locations (various kinds of overlays and/or intermediate boxes capable of performing keylogging and/or modified display presentation). The personal cellphone and/or PDA ... with user owned display and key entry is a countermeasure to various kinds of MITM attacks on terminals in public /or unsecured locations (user has no way of easily proofing that they aren't faced with some form of compromised terminal environment). -- Anne Lynn Wheeler http://www.garlic.com/~lynn/
Adding reliability and trust to smartcards
IST Results - Adding reliability and trust to smartcards http://istresults.cordis.lu/index.cfm/section/news/tpl/article/BrowsingType/Features/ID/70511 of course ... reliability and trust is more than just the smartcards ... it assurance and trust related to the smartcard infrastructre ... not just the cards themselves. recent posting on eal5 evaluation, somewhat related http://www.garlic.com/~lynn/2004m.html#41 EAL5 other parts of the thread http://www.garlic.com/~lynn/2004m.html#49 EAL5 http://www.garlic.com/~lynn/2004m.html#50 EAL5 semi-related posts about infrastructure http://www.garlic.com/~lynn/aadsm18.htm#39 Financial identity is *dangerous*? (was re: Fake companies, real money) http://www.garlic.com/~lynn/aadsm18.htm#40 Financial identity is *dangerous*? (was re: Fake companies, real money) -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [off-topic, but not by ukcrypto standards] ukcrypto-moderated pre-moderators needed
Peter Fairbrother wrote: Ben Laurie wrote: OK, since my previous attempt to create a lower volume ukcrypto-like-thing failed, I have concluded that the only way to handle the problem is to produce a moderated version of ukcrypto. I know for sure there's demand for this, but I also know that the volume is too high for traditional moderation methods (at least too high for _me_ to use traditional moderation). I have a question. What do you think is on topic? The original charter, as I understand it, was to discuss UK legislation relating to cryptography - which is fine, but very little is happening in that area right now, and there would be virtually no posts. I would include privacy and anonymity as well as cryptography. I'm open to persuasion for other topics. Killing time isn't one of them. -- ApacheCon! 13-17 November! http://www.apachecon.com/ 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: Financial identity is *dangerous*? (was re: Fake companies, real money)
Ian Grigg wrote: Alan Barrett wrote: On Sat, 23 Oct 2004, Aaron Whitehouse wrote: Oh, and make it small enough to fit in the pocket, put a display *and* a keypad on it, and tell the user not to lose it. How much difference is there, practically, between this and using a smartcard credit card in an external reader with a keypad? Aside from the weight of the 'computer' in your pocket... The risks of using *somebody else's keypad* to type passwords or instructions to your smartcard, or using *somebody else's display* to view output that is intended to be private, should be obvious. :-) It should be obvious. But it's not. A few billions of investment in smart cards says that it is anything but obvious. That assumes that the goal of smartcards is to increase security instead of to decrease liability. -- ApacheCon! 13-17 November! http://www.apachecon.com/ 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]
Trio try for better mobile security
http://www.vnunet.com/print/1159101 vnunet.com Trio try for better mobile security The Trusted Mobile Platform from Intel, IBM and NTT DoCoMo aims to make mobiles a better bet for secure networking Daniel Robinson, IT Week 01 Nov 2004 Intel, IBM and mobile communications company NTT DoCoMo last week announced a set of security specifications for mobile client devices. They said the aim is to create a secure architecture for future wireless data services. The Trusted Mobile Platform specification, available via the link below, defines a set of hardware and software components plus communication protocols that can be used to build devices with various levels of security. It is intended to be an open standard, according to NTT DoCoMo chief executive Takanori Utano. The specification defines three classes of trusted mobile device (TMD), ranging from handsets with no hardware security features to those that include a trusted platform module (TPM) to handle cryptography functions and hardware-enforced separation between trusted and untrusted applications and their data. It also defines a set of protocols that allow a TMD to communicate with other platforms more securely The partnership brings together Intel's expertise in silicon and wireless devices, IBM's experience of business security and NTT DoCoMo's knowledge of security in wireless networks, the companies said. This collaboration enhances handheld architectures to provide the trusted capabilities vital for widespread adoption of mobile commerce and enterprise usage, said Intel vice-president Sean Maloney. Chip designer ARM already includes technology called TrustZone in its latest processor cores to provide separation between secure and non-secure code. Although Intel uses ARM technology in its XScale mobile chips, the company has not disclosed whether the Trusted Mobile Platform supports technologies such as TrustZone. -- - 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]
US deploys anti-satelite equipment
WASHINGTON (Reuters) -- The U.S. Air Force quietly has put into service a new weapon designed to jam enemy satellite communications, a significant step toward U.S. control of space. http://www.cnn.com/2004/TECH/space/11/01/satellite.jamming.reut/index.html Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: AES Modes
DJ, On Oct 13, 2004, at 10:59 AM, [EMAIL PROTECTED] wrote: On the IEEE 802 standards track, CCM and GCM have traction. CCM has been in 802.11 for a while and the 802.16-2004 was published last week, supplanting the broken DES-CBC mode with AES-CCM. For wireless systems, we know and like CCM and it's going to take a lot to oust it. I'm aware of a handful of other wireless protocols in development that appear to be all headed the CCM way. GCM proposed for 802.1ae linksec. This is the 'fast' mode for wired ethernet. For packetised traffic below 1Gbps, CCM works just great. The CTR and CBC parts of CCM run in parallel in hardware, making the basic latency = 1 AES (which is 11 clocks in a simple implementation). With a bit of HW loop unrolling and pipelining, I can do CCM upto several gigabits. CCM nicely matches the structure of packets. Namely 1) Get header - Process additional authenticated data 2) Get payload - Process MAC and encryption in parallel. So it is not a bear to implement in a typical communications datapath IC, where things are presented to you in this order. GCM allows block level parallelism up to a point. I'm not sure what you mean here. Is there some limitation that you have in mind? Hence enabling me to put lots of parallel AES blocks on a chip and go at multi gigabits without breaking a sweat. It does however have all that Galois arithmetic to do per block, which increases the path depth a bit. There is however a fundamental speed problem with packet oriented AES based modes. The parallelism you can achieve on things like GCM requires that you have multiple blocks to run in parallel. If I get a large number of small packets, each 128 bits long, then there's nothing to do in parallel at the block level and so my speed limit is determined by how fast I can run 11 rounds of AES. I'm not quite sure what you mean here, but GCM can be implemented with a single AES pipeline and a single GF(2^128) multiplier such that data from multiple packets can be in the pipeline at the same time. In fact, this was a design requirement for GCM; the other authenticated encryption modes lack this property and their performance suffers for it when used for packet encryption at high data rates. There is an analysis of this issue in Section 3.1. of http://eprint.iacr.org/2004/193/ that includes a comparison between GCM, CWC, and OCB. Here is the result: GCM is the only authenticated encryption mode that doesn't stall its AES pipeline each time a new packet comes in, and this enables it to go twice as fast as CWC and three times as fast as OCB on Internet data, in the case in which a single AES pipeline is used. (Other modes aren't in the contest, since they use chaining.) This may come to bite us in the future and when we start having to protect data pushing the terabits, we either need larger packets or something different in the crypto. One way is to protect over large packet aggregates, but no 802 level protocol is set up to support it. Stream ciphers look attractive here, we can make them go *really* fast in hardware. CTR and GCM can be fully pipelined; I'm not sure what a stream cipher could do that would be better. I guess one potential improvement would be lower latency due to reduced pipeline depth. But I don't understand where a stream cipher would get the increase in data throughput that you're alluding to. Best regards, David Another frustrating aspect of the current crop of modes is frame expansion. Throwing in an 8 byte nonce and an 8 byte ICV per packet is a heavy overhead. Deriving nonces from the protocol state is generally not wise since the frame counts are either non existant (802.3, 802.11) or not secured (802.16). In the coming years, I would like to see link protocols (I.E. 802.*) move link security down to the PHY, to protect management and data traffic equally, to secure the protocol state as well as data and so to reduce packet overhead. I would also like to see the standardized crypto and protocols be structured to work over larger aggregates of packets, protecting the structure of transmission as well as the content and allowing much greater levels of parallelism in the HW implementations. Obviously, none of this is very relevant above layer 2. Regards, DJ From: Ian Grigg [EMAIL PROTECTED] Sent: Oct 10, 2004 11:11 AM To: Metzdowd Crypto [EMAIL PROTECTED] Subject: AES Modes I'm looking for basic mode to encrypt blocks (using AES) of about 1k in length, +/- an order of magnitude. Looking at the above table (2nd link) there are oodles of proposed ones. It would be nice to have a mode that didn't also require a separate MAC operation - I get the impression that this is behind some of the proposals? I think CCM is just about perfect for this goal. The MAC isn't free, but it's integrated into the chaining mode. There are also some patented modes that provide a MAC for almost no extra computation(OCB, IACBC), and some proposed modes that
Re: Financial identity is *dangerous*? (was re: Fake companies, real money)
Ben, Ian Grigg wrote: It should be obvious. But it's not. A few billions of investment in smart cards says that it is anything but obvious. That assumes that the goal of smartcards is to increase security instead of to decrease liability. On whether the goal of smart cards is to reduce liability: a) Not with any systems I was familiar: the major Dutch systems were defensive, oriented to filling the space that was potentially threatened by other parties. The trials were goaled to increase security, which they did not by using smart cards, but by eliminating cash, which had created an unacceptable risk of serious theft in unattended petrol stations. The same happened with UK phone cards... I'm unfamiliar with Mondex or the Belgium/ Proton based motives, but their structures indicate that liability was not a question uppermost on their minds. b) Liability reduction cannot be a goal. If it was, then one could achieve the goal completely - eliminate liability - by not doing the project. Instead, liability and/or reduction of same is a _limitation_ on the goal of the system. c) Whether liability reduction entered into any smart card system as a limitation on their goals is a little uncertain. I would say no, as all the systems were early stage in the institutional model; in which case there was little or no liability. Instead, the only drivers in that vague area would have been future running costs reduction, which would have included well considered security models, and partially considered user support models, to reduce over all costs. Including all forms of risks, of course. d) Liability reduction generally comes into play when a system is mature and/or regulatory issues come into play. That is, liability reduction is something often seen when the desire is to avoid surprises, and to avoid any costs cropping up that weren't well built into the costs model. I.e., the risk models used by credit card operators are one example, and the customer agreement models (or whatever they are called) used by CAs are another example of liability reduction. e) Perversely, banks practice liability increase as well as reduction. In fact, a pure banking model is about the risk of a loan, and they specialise in measuring and managing the risk of that loan. But, as we are talking about payment systems, and loans are banking, and banking is not payment systems, that would be a change in business, so out of scope of the original topic. f) And, of course, all institutions will practice liability increase if they can turn it into a barrier to entry, that is, cartelise the industry so as to block new entrants. See the eMoney directive for the European barrier to entry, which was effectively coordinated by the Bundesbank on behalf of the banks, and resulted in the like a bank, but not a bank, and as costly as a bank approach to digital cash. All of which might or might not hit the target of liability as you wrote it? iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
