Cryptophone locks out snoopers
(link is very slow:) http://theregister.co.uk/content/68/34096.html Cryptophone locks out snoopers By electricnews.net Posted: 20/11/2003 at 10:16 GMT A German firm has launched a GSM mobile phone that promises strong end-to-end encryption on calls, preventing the possibility of anybody listening in. If you think that you'll soon be seeing this on the shelves of your local mobile phone shop though, think again. For a start, the Cryptophone sells for EUR1,799 per handset, which puts it out of the reach of most buyers. Second, the phone's maker, Berlin-based GSMK, say the phone will not be sold off the shelf because of the measures needed to ensure that the product received by the customer is untampered with and secure. Buyers must buy the phone direct from GSMK. According to GSMK, the new phone is designed to counteract known measures used to intercept mobile phone calls. While GSM networks are far more secure than their analogue predecessors, there are ways and means to circumvent security measures. The encryption in GSM is only used to protect the call while it is in the air between the GSM base station and the phone. During its entire route through the telephone network, which may include other wireless links, the call is not protected by encryption. Encryption on the GSM network can also be broken. The equipment needed to do this is extremely expensive and is said to be only available to law enforcement agencies, but it has be known to fall into the hands of criminal organisations. The Cryptophone is a very familiar-looking device, since it is based around the same HTC smartphone that O2 used as its original XDA platform. The phone runs on a heavily modified version of Microsoft Pocket PC 2002. GSMK says it is the only manufacturer of such devices that has its source code publicly available for review. It says this will prove that there are no back-doors in the software, thus allaying the fears of the security-conscious. Publication of the source code doesn't compromise the phone's security, according to GSMK. The Cryptophone is engineered in such a way that the encryption key is only stored in the phone for the duration of the call and securely erased immediately afterwards. One drawback of the device is that it requires the recipient of calls to also use a Cryptophone to ensure security. GSMK does sell the device in pairs, but also offers a free software download that allows any PC with a modem to be used as a Cryptophone. GSMK says that the Cryptophone comples with German and EU export law. This means the device can be sold freely within the EU and a number of other states such as the US, Japan and Australia. It cannot be sold to customers within Afghanistan, Syria, Iraq, Iran, Libya and North Korea. A number of other states are subject to tight export controls and a special licence will have to be obtained. © ElectricNews.Net - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Fwd: "Bedazzled" Log-in Method Whitepaper
"Bedazzled" Log-in Method Whitepaper Author: George Hara (http://www.filematrix.xnet.ro/ideas/whitepapers/login.htm) Introduction Using strings of characters as passwords has always been a security issue because they are hard to remember and can be stolen by key-loggers or screen-text harvesters. It will still be an issue for personal computers, but there is another method available for authentication over the Internet (where are the highest security concerns). This method involves no special technologies, but simply a new vision on how to bring existing technologies together. The method is easier to use than text passwords, but it requires, from the users, the protection of their personal computers (where they need text-password log-in and encryption), just as they do now. The "Bedazzled" log-in method uses a (public) user name / ID (for example, the user's email address) and a number of images, called password images, for authentication. The images have to be generated (by the authentication service) during the creation of the account for which the authentication will be later required. Each image is a small, PNG compressed, bulk of pixels with random colors. The PNG compression is used because a true-color image is compressed without losses, with a very high rate. In the case of random images this doesn't help, but, as you'll read below, in the User images section, this is the best format. Each image should contain something like 50 * 50 true-color pixels (24 bits). This means that the total number of combinations of such a random image is 24 ^ (50 * 50), that is over 10 ^ 3450. Basically, a particular case is unbreakable through brute force search. Authentication -- The authentication is the classic method: the user is identified by his user name, and then he is authenticated by comparing all images specified in the log-in form, with the images stored on the computer which makes the authentication. If all images are *identical*, and put in the same order (im age 1 as password 1, image 2 as password 2...), the user is authenticated. If they are not identical, the user is rejected. Implementation --- To make the "Bedazzled" log-in method easy to use, the password images must be saved on the user's computer, preferably in encrypted files (see file encryption under WindowsXP, or PGP encrypted drives). Since the "Bedazzled" log-in method is supposed to be used over Internet, it is necessary for the user to be able to drag-and-drop each image onto the browser, in the log-in form. This way, the log-in form has access to the password images, and can download them to the authentication server when the user clicks the "Log-in" button. As you can see, the method is very eay to use, but in order to make it even easier, the log-in form should display a small file browser which should be used to navigate to the password images (they should all be in the same directory, for easy user access). The log-in form should save a cookie on the user's computer in order to automatically open the file browser at the same location, the next time the user attempts to authenticate himslef. User images There is no need for the images to be random. The user could choose his own images when he creates an authentication account, being only limited to a specific file size (like 20 KB / image). He could simply take some images from his computer and resize them to fit the size limit; the images should be compressed without loss (preferably in a PNG format), just in case they are lost but the original bigger images still exist and can be resized again with the same algorithm (to generate the same password image). Another method requires a small program which takes a string of characters typed by the user, and converts them through a hash algorithm into an apparently random image. This method makes it possible to recreate the password images if the user remembers the string of characters, without the need of storing any information. TEMPEST protection -- First of all, since the user doesn't need to type anything and the password images don't need to be displayed, the passwords are protected from TEMPEST atacks. However, the user may need to navigate through his pictures and choose the correct password images for each log-in form. This would create a potential security breach. The "Bedazzled" log-in method has intrinsic TEMPEST protection to this kind of breach because when a monitor displays an image, the colors of each pixel is not displayed exactly as indicated by the bits that make the picture. Each monitor has its own way of displaying the image. Besides, users always alter the image by chaging various parameters of the monitor's image: brightness, contrast, color balance, color temperature, gamma. On the other end of the TEMPEST technology, the "reader" takes a snapshot of the image displayed by the monitor. This is like making a scan of a print of a digital image
Open Source Embedded SSL - Export Questions
Hi All, We've implemented a small version of SSL that we plan to release as open source by year's end. I've seen some discussion on this group indicating that this would be useful in the embedded environments, given the current landscape of larger implementations such as OpenSSL (Crypto++, etc). We developed this ourselves (using some of the crypto routines in Tom's libtomcrypt) as part of our Web services based device management software because we needed to keep our own footprint small, and I imagine there are others looking to do the same. Once our code is released, we welcome feedback in terms of additional requirements, gotchas, etc. (and if you want to jump in now, that's fine too). But before we can release, we need to understand the export issues (we're a US based company). An overview of what we're developed for the first release: SSLv3 protocol implementation Simple ASN.1 parsing Cipher suites: TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA We're not looking for official legal advice, just some pointers to current online resources of how to go about registering our product in the US. I've seen posts that for SSL implementations you "just need to send a letter to the government", but haven't come across an official government checklist and address. We may be able to weaken the code down using the export ciphers, but I doubt end users will be interested in that level of encryption. Plus, if we do have to limit key lengths, it seems a bit arbitrary with open source code, since users can simply change a few lines of code and have full strength crypto. Are there any special provisions for source release (short of getting a tattoo, singing an mp3 or sending a model rocket over to Mexico - kidding, kidding)? We'd appreciate feedback or pointers to documentation on the steps required for government registration and an approximate timeframe for the process. On a different, but similar legal note, what current patent/trademark issues have people run across with the algorithms mentioned above? RSA patents expired a few years ago and our ARC4 implementation is not trademarked as far as I understand (although most books on the subject seem a bit squirrelly). Open source crypto libraries include implementations of these and other disputed algorithms including DSS and ECC, so I'm wondering how they handled the situation. Thanks, J Harper PeerSec Networks http://www.peersec.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
