Death of antivirus software imminent
re: Storm, Nugache lead dangerous new botnet barrage http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1286808,00.html from above: The creators of these Trojans and bots not only have very strong software development and testing skills, but also clearly know how security vendors operate and how to outmaneuver defenses such as antivirus software, IDS and firewalls, experts say. They know that they simply need to alter their code and the messages carrying it in small ways in order to evade signature-based defenses. Dittrich and other researchers say that when they analyze the code these malware authors are putting out, what emerges is a picture of a group of skilled, professional software developers learning from their mistakes, improving their code on a weekly basis and making a lot of money in the process. ... snip ... ... and somewhat related Virtualization still hot, death of antivirus software imminent, VC says http://www.networkworld.com/news/2007/121707-crystal-ball-virtualization.html from above: Another trend Maeder predicts for 2008 is, at long last, the death of antivirus software and other security products that allow employees to install and download any programs they'd like onto their PCs, and then attempt to weed out the malicious code. Instead, products that protect endpoints by only allowing IT-approved code to be installed will become the norm. ... snip ... and post about dealing with compromised machines http://www.garlic.com/~lynn/2007u.html#771 folklore indeed mentioning sophistication in other ways: Botnet-controlled Trojan robbing online bank customers http://www.networkworld.com/news/2007/121307-zbot-trojan-robbing-banks.htm from above: If the attacker succeeds in getting the Trojan malware onto the victim's computer, he can piggyback on a session of online banking without even having to use the victim's name and password. The infected computer communicates back to the Trojan's command-and-controller exactly which bank the victim has an account with. It then automatically feeds code that tells the Trojan how to mimic actual online transactions with a particular bank to do wire transfers or bill payments ... snip ... there have been some number of online banking countermeasures for specific kinds of system compromises like keyloggers ... but they apparently didn't bother to get promises from the crooks to only limit the kinds of attacks to those exploits. some related comments on such compromised machines http://www.garlic.com/~lynn/aadsm27.htm#66 2007: year in review http://www.garlic.com/~lynn/aadsm28.htm#0 2007: year in review - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 2008: The year of hack the vote?
Dan wrote: Let's not do this or we'll have to talk about JF Kennedy who, at least, bought his votes with real money. That's because Democrats had become more professional, and the tradition of buying votes with whiskey only works for the retail level, not wholesale. Dan also wrote: May I point out that if voting systems have a level of flaw that says only an idiot would use them, then how can you explain electronic commerce, FaceBook, or gambling sites? More people use just those three than will *ever* vote. The primary threats of electronic voting machines aren't to the individual voter, who can slightly increase the chances of getting his/her vote counted accurately by insisting on paper ballots, but to the aggregate vote count, which can be hacked if the precinct has _any_ electronic machines. The big problem in Ohio appears to have been Denial of Service - not that there weren't lots of other problems, but electronic voting systems have sufficient complexity that an elections department can arrange to have enough missing parts or supplies or passwords or powercords or whatever in demographically appropriate precincts so that the results get skewed even without Other Technical Means. Some of the black inner-city precincts had two-hour lines (on a rainy day), while white Republican-leaning precincts had all the equipment they needed. (Also, if you're saying only an idiot would use it and ask how gambling sites exist, the answer is that only idiots gamble... As Ed Gerck pointed out, risk in e-commerce can be managed and amortized into the price, but that doesn't work for voting.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Question on export issues
Alan writes: -+ | What are the rules these days on crypto exports. Is a review | still required? If so, what gets rejected? | The following is a recent interaction with specialty export counsel, though somewhat modified as I detoxed it from base64 to ASCII plaintext and from infinite line length to fixed line length. When you file, you have immediate permission to export to, essentially, the anglophone democracies and western Europe. If you have heard nothing in 30 days elapsed time, you are then free to export generally but you will never be permitted to export to the embargoed country list (Cuba, Iran, Sudan, Syria, North Korea, and Libya). YMMV. --dan -8cut-here8- A. BIS Checklist of Questions: 1. Does your product perform cryptography, or otherwise contain any parts or components that are capable of performing any of the following information security functions? (Mark with an X all that apply) a. _ encryption b. _ decryption only (no encryption) c. _ key management / public key infrastructure (PKI) d. _ authentication (e.g., password protection, digital signatures) e. _ copy protection f. _ anti-virus protection g. _ other (please explain) : ___ h. _ NONE / NOT APPLICABLE 2. For items with encryption, decryption and/or key management functions (1.a, 1.b, 1.c above): a. What symmetric algorithms and key lengths (e.g., 56-bit DES, 112 / 168-bit Triple-DES, 128 / 256-bit AES / Rijndael) are implemented or supported? b. What asymmetric algorithms and key lengths (e.g., 512-bit RSA / Diffie-Hellman, 1024 / 2048-bit RSA / Diffie-Hellman) are implemented or supported? c. What encryption protocols (e.g., SSL, SSH, IPSEC or PKCS standards) are implemented or supported? d. What type of data is encrypted? B. BIS Review Requirements for Form 748-P. If any inquiry is not applicable, please state N/A. (a) State the name of the encryption item being submitted for review. i. Enter the name of the manufacturer of the software. ii. Provide a brief technical description of the basic purpose to be served by the encryption; iii. Provide a brief description of the type of encryption used in the software; e.g., 168-bit Triple DES for xyz purpose, and 1024-bit RSA for abc purpose. (b) You would also need to provide brochures or other documentation as well as specifications related to the software, relevant product descriptions, architecture specifications and, if required by BIS, source code. You must also indicate whether there have been any prior reviews of the product, if such reviews are applicable to the current submission. In addition, you must provide the following information in a cover letter accompanying your review request: (1) Description of all the symmetric and asymmetric encryption algorithms and key lengths and how the algorithms are used. Specify which encryption modes are supported (e.g., cipher feedback mode or cipher block chaining mode). (2) State the key management algorithms, including modulus sizes, that are supported. (3) For products with proprietary algorithms, include a textual description and the source code of the algorithm. (4) Describe the pre-processing methods (e.g., data compression or data interleaving) that are applied to the plaintext data prior to encryption. (5) Describe the post-processing methods (e.g., packetization, encapsulation) that are applied to the cipher text data after encryption. (6) State the communication protocols (e.g., X.25, Telnet or TCP) and encryption protocols (e.g., SSL, IPSEC or PKCS standards) that are supported. (7) Describe the encryption-related Application Programming Interfaces (APIs) that are implemented and/or supported. Explain which interfaces are for internal (private) and/or external (public) use. (8) Describe the cryptographic functionality that is provided by third-party hardware or software encryption components (if any). Identify the manufacturers of the hardware or software components, including specific part numbers and version information as needed to describe the product. Describe whether the encryption software components (if any) are statically or dynamically linked. (9) For commodities or software using Java byte code, describe the techniques (including obfuscation, private access modifiers or final classes) that are used to protect against decompilation and misuse. (10) State how the product is written to preclude user modification of the encryption algorithms, key management and key space. (11) For products which incorporate an open cryptographic interface as defined in part 772 of the EAR, describe the Open Cryptographic Interface. (12) We must provide sufficient information for BIS to determine whether the software qualifies for mass market consideration. The regulations offer examples
Philips/NXP/Mifare CRYPTO1 mostly reverse-engineered
From http://cryptanalysis.eu/blog/2007/12/29/mifare-crypto1: MiFare’s CRYPTO1 stream cipher has captured my attention for a while. However, hardware reverse-engineering is not a field I actively engage in. So I was very happy when Karsten Nohl (University of Virginia), Starbug and Henryk Plötz gave a talk at the 24C3 [the 24th Congress of the Chaos Computer Club taking place in Berlin at this very moment] yesterday evening showing that they have reverse-engineered most parts of this cipher. CRYPTO1 uses a 48-bit LFSR-based filter generator to generate key stream. The filter function - if I understood correctly - uses 20 taps (this was not mentioned in the talk, I asked Karsten privately about this) however the degree of the boolean function implementing the filter, thus it remains to be seen whether algebraic attacks can be applied. Even if no algebraic attacks are applied, a BSW sampling TMTO will break CRYPTO1 completely. This was pretty obvious before they gave their talk, but now vendors actually have to worry about this being out in the wild once the feedback and the filter function have been revealed. My colleague Erik took photos of the slides which I put up on Zooomr [0]. A video recording of the talk should be available shortly and will be linked here. [0] http://www.zooomr.com/photos/ralf/sets/26758/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Question on export issues
In my personal experience, if you are developing a mass-market item with conventional crypto (e.g., SSL, S/MIME, etc ) then it is fairly routine to get a commodity export license which lets you sell globally. Disclaimers abound, including that I'm not a lawyer and certainly don't speak for IBM. /r$ -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
