Remove Certificate From Nokia E61

Somehow, people are directed to my website by queries which contain the following key-words; 'remove', 'certificate', and 'e61'. So, here's a quick certificate uninstall guide:

Menu -> Tools -> Settings -> Security Settings -> Certif. management -> Scroll down to the certificate you wish to delete -> Options -> Delete -> Confirm Delete -> Yes.

It's not that hard :) (the 'guide' is written for the e61i, but I doubt if it's much different on the e61)

Click to read more ...

'Faking' CA's

A while back, I was asked if it's possible to fake a VeriSign issued SSL certificate. In theory, this is possible (if you have like unlimited resources), but on the practical side, it's impossible. It is possible however to create a CA which resembles the VeriSign root up to some level. Everything, apart to some 'details', can be forged. Name, serial number, timestamps, additional fields etc., can be created by OpenSSL and a special crafted config file. It's just finding out how to do it. The tough (and this is a definite understatement) part is the thumbprint, and the public key. The public key is generated by cryptographic algorithme (along with the private key), and it's impossible to 'regenerate' this. But for the casual user, this is not a problem. For a normal user it's pretty hard to tell the original from the fake CA certificate, since only details are different. Also, these differences are unreadable pieces of hexadecimal strings. So all you have to do is to persuade the user to trust the new (and improved) VeriSign CA, and every site he visits may be fraudulent (and probably is). The following sections contain the real certificate from VeriSign, and the fake one. Now you figure out which one is the real one.

Certificate: Data: Version: 1 (0x0) Serial Number: 02:ad:66:7e:4e:45:fe:5e:57:6f:3c:98:19:5e:dd:c0 Signature Algorithm: md2WithRSAEncryption Issuer: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority Validity Not Before: Nov 9 01:00:00 1994 GMT Not After : Jan 8 01:00:00 2010 GMT Subject: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1000 bit) Modulus (1000 bit): 00:b8:93:ae:c9:5e:c7:8a:9e:97:c7:c3:32:00:73: 45:54:03:db:29:e2:13:4b:7b:78:6e:57:69:b3:c8: 77:a4:a7:48:40:51:99:1b:86:9f:f2:e7:8d:34:40: fc:99:91:ac:ed:2e:07:7b:da:f6:97:b3:e7:63:2c: 7c:14:c4:8a:61:8f:e4:96:02:40:40:e4:ba:9a:bb: 6a:cb:d9:75:78:00:b7:5f:b3:ca:1b:a8:1f:6b:5b: 44:e3:65:04:72:98:55:5c:fb:e2:2d:bc:46:eb:c7: 44:78:5c:bf:9a:b4:a3:19:a5:d9:17:47:87:bb:73: 12:60:b9:77:18:59 Exponent: 65537 (0x10001) Signature Algorithm: md2WithRSAEncryption 61:29:b8:7b:55:3b:c6:c7:7c:ed:86:73:b8:30:4a:02:c0:93: 79:06:83:39:f2:9c:9e:40:ca:42:e6:7f:12:e2:7c:22:d3:2b: d6:8f:a7:d9:a4:93:20:09:9a:6b:26:71:65:bb:ff:dc:70:fb: d9:5c:a2:34:c6:88:00:ec:51:8a:65:75:53:d4:18:a3:38:f5: d3:61:14:7b:8f:e4:d2:b3:fe:39:45:7a:4d:ec:f5:35:61:d7: 22:9a:2c:1a:c8:d2:f7:d1:55:4d:02:83:cc:f0:fc:5c:32:a9: 49:d3:d2:2c:5a:c9:b8:9f:b5:d7:7f:3a:9a:b5:d8:55:9d

And the second CA certificate

Certificate: Data: Version: 1 (0x0) Serial Number: 02:ad:66:7e:4e:45:fe:5e:57:6f:3c:98:19:5e:dd:c0 Signature Algorithm: md2WithRSAEncryption Issuer: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority Validity Not Before: Nov 9 00:00:00 1994 GMT Not After : Jan 7 23:59:59 2010 GMT Subject: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1000 bit) Modulus (1000 bit): 00:92:ce:7a:c1:ae:83:3e:5a:aa:89:83:57:ac:25: 01:76:0c:ad:ae:8e:2c:37:ce:eb:35:78:64:54:03: e5:84:40:51:c9:bf:8f:08:e2:8a:82:08:d2:16:86: 37:55:e9:b1:21:02:ad:76:68:81:9a:05:a2:4b:c9: 4b:25:66:22:56:6c:88:07:8f:f7:81:59:6d:84:07: 65:70:13:71:76:3e:9b:77:4c:e3:50:89:56:98:48: b9:1d:a7:29:1a:13:2e:4a:11:59:9c:1e:15:d5:49: 54:2c:73:3a:69:82:b1:97:39:9c:6d:70:67:48:e5: dd:2d:d6:c8:1e:7b Exponent: 65537 (0x10001) Signature Algorithm: md2WithRSAEncryption 65:dd:7e:e1:b2:ec:b0:e2:3a:e0:ec:71:46:9a:19:11:b8:d3: c7:a0:b4:03:40:26:02:3e:09:9c:e1:12:b3:d1:5a:f6:37:a5: b7:61:03:b6:5b:16:69:3b:c6:44:08:0c:88:53:0c:6b:97:49: c7:3e:35:dc:6c:b9:bb:aa:df:5c:bb:3a:2f:93:60:b6:a9:4b: 4d:f2:20:f7:cd:5f:7f:64:7b:8e:dc:00:5c:d7:fa:77:ca:39: 16:59:6f:0e:ea:d3:b5:83:7f:4d:4d:42:56:76:b4:c9:5f:04: f8:38:f8:eb:d2:5f:75:5f:cd:7b:fc:e5:8e:80:7c:fc:50

After creating the CA, I made the SSL certificate (some data has been obscured).

Certificate: Data: Version: 3 (0x2) Serial Number: 1a:b6:68:61:a3:c7:c5:ca:a0:b8:4f:09:c1:97:0e:f4 Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority Validity Not Before: Apr 18 15:17:43 2007 GMT Not After : Apr 17 15:17:43 2008 GMT Subject: C=NL, ST=Noord-Holland, L=Amsterdam, O=###########., OU=#####, OU=Terms of use at www.verisign.com/rpa (c)00, CN=www.#######.nl Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:b5:b7:78:80:6f:a9:3d:d0:d8:99:8e:0c:d3:34: f2:95:d5:1b:a4:30:44:45:6c:11:71:9b:dc:ae:b7: 3c:1e:0a:5b:81:2d:bd:e6:be:34:cb:7c:e2:de:5f: 20:1f:df:0d:36:ad:83:74:64:b7:52:34:10:f0:bd: 72:09:cf:31:84:77:81:c1:01:16:1d:a5:e9:58:27: 8f:f6:ea:20:15:04:e6:b9:40:d0:16:3f:b9:f3:cb: 06:75:9c:2c:93:d1:55:6e:04:f0:e1:43:6b:53:16: 39:ee:b3:84:62:02:eb:f8:f0:df:74:f4:da:6e:3a: 8a:6b:4a:ab:be:c1:16:9e:d3 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Key Usage: Digital Signature, Key Encipherment X509v3 CRL Distribution Points: URI:http://crl.verisign.com/RSASecureServer.crl X509v3 Certificate Policies: Policy: 2.16.840.1.113733.1.7.23.3 CPS: https://www.verisign.com/rpa; X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication Authority Information Access: OCSP - URI:http://ocsp.verisign.com 1.3.6.1.5.5.7.1.12: 0_.].[0Y0W0U..image/gif0!0.0...+..............k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif Signature Algorithm: sha1WithRSAEncryption 87:d1:47:c7:ea:59:18:9c:8d:e6:17:53:9c:76:d4:fb:bb:ce: ab:ab:3f:8a:a6:74:98:67:86:53:39:79:98:62:89:e5:07:27: 73:db:65:9f:10:8c:51:6e:ca:bc:cb:25:46:49:49:8f:0c:b4: 2c:f8:3b:47:95:c2:ba:8c:5e:d8:54:52:83:d5:4d:ed:b2:95: 0b:62:13:1e:9a:61:7c:97:b7:f9:02:52:7a:4f:7a:c6:19:f3: 80:3a:99:6e:27:5b:b2:b8:80:c1:43:d1:b9:0b:9f:02:26:9c: 50:39:a1:18:82:cd:cd:89:dd:ca:5e:e1:52:02:ab:bf:b1

The second CA is the real thing. The first one is the fake CA. So all you have to do is to persuade the user to trust the new (and improved) VeriSign CA, and every site he visits may be fraudulent (and probably is). Or just infect him/her with a trojan to insert the CA for you. The 'fun' part is that if you should replace the actual (original) VeriSign CA in your crypto store you get warnings/error messages which aren't very clear. The OS/Browser tries to 'tie' the SSL certificate to the CA, but not everything seems to add up :).

Click to read more ...

Wireless Standards???

First there were wireless networks, then there was WEP. WEP was the protective layer for wireless, so that your data was (kinda) secure when it traveled through the air. This layer was compromised rather quick, so alternatives were needed. The initial alternative was WPA. This new layer of protection was a lot stronger (there still isn't a way of hacking this quickly). Downside was that it took a while to become a standard, so every vendor was free to use it as they saw fit. This could result into incompatibility issues when you used different vendors in your wireless environment. The final WPA standard became WPA2, and was to overcome the incompatibility issues with the earlier WPA.... NOT!!! Most consumer wireless products in my vicinity just won't connect properly using WPA2 (with either AES or TKIP). The only thing that keeps working is WPA. When connecting to a wireless network which is protected with WPA2, everything seems to go fine, but when you want to transfer data, nothing happens. Also, the wireless base station doesn't show any association with the client. What is wrong with this picture? Does this mean that there are also different implementations of WPA2 among vendors? A quick WPA2 configuration with a 32 character (or 16 character) WPA2-PSK key just won't work, while the client devices all support at least WPA2-PSK with TKIP.

Click to read more ...

Do You Trust 'Kozjegyzoi Tanusitvanykiado'?

Updated on Wednesday, June 15, 2011 at 11:53 by Willem

Perhaps you don't, but your computer does! At this moment there are over a hundred Trusted Root Certifications Authorities in your browser or Operating System. Many of those don't mean anything to me. When a Trusted Root Certification Authority is available in your browser or OS, you don't get any questions/pop-up that your entering a secured Internet connection. This means that the certificate was issued by someone trustworthy. Who decides who or what company is trustworthy? I know most of the commercial SSL vendors like VeriSign, Thawte, Comodo, Equifax, Entrust, and Cybertrust. Those are the companies which sell most of the SSL certificates used on the Internet. But I haven't heard of Kozjegyzoi Tanusitvanykiado or IPS Seguridad. So do I want to trust certificates issued by them? It would be nice if the browser had an extra message box (yes, another message box :-) ) to verify with the user if the CA should be trusted from this point on. This way the (pro-)user gets to decide if he wants to trust the CA (without the trouble of manually verifying the CA details on the CA website), and the basic user may rely on the recommendation from the OS/browser.

This way I can decide for myself if I want to trust some post-office in Japan or Germany.

Click to read more ...

Import Root CA in the Nokia E61

Last week, I recieved my new Nokia E61i. As soon as I tried to connect to my own IMAP server (over SSL/TLS) is started nagging about the (selfsigned) SSL certificate.

The E61 has a certificate store, so I should be able to add other Root CA's to this store, but this is where the trouble began.

The manual has a chapter on certificates, but it lacks a working explanation on "how to import third party root CA's". On my old iPaq, it was simply upload a DER encoded certificate, click on it, and it would install. Well this doesn't work on the E61 (and many other Symbian-based) phones. Just 'google', and you'll find lot's of people with similar problems...

The working solution I found uses a website from which you download the certificate with the phone, but there is a catch; you need to add a MIME-type to the website containing the certificate (hence the admin rights).

Click to read more ...

AACS 'Advantages'

The last couple of days were all about the leaked key for decrypting HD-DVD movies. This made me curious about the technology, so I headed to the AACS LA website. There's variety of white papers available, which explain the AACS concept. The same papers were used by musilix64 in making his first breakthrough on circumventing the AACS protection. But there is more to be found on their website... There's even a section which explains the Consumer Benefits of AACS.

• Support a superior viewing experience delivered by next generation media formats AACS is added to the content. The content itself will probably 'work' better without AACS.
• Enable greater flexibility to manage distribute, and play entertainment content on a wider range of devices This is a 'feature' for the publishing companies. Without the restrictive AACS protection, the content can be played on virtually every device. With AACS protection 'they' control on which device you can play the content.
• Enable groundbreaking home entertainment choices and the ability to use content on PCs and a range of CE devices AACS is added to the content. The content itself will probably 'work' better without AACS.
• Work across a variety of formats and platforms Five letters: L I N U X. AACS protected movies CANNOT be played on Linux. Only movies without the protection can be player on certain Linux players.

Click to read more ...

Illegal HEX codes

As some of you might know, the protection of Blu-Ray, and HD-DVD movies is based on a 'secret' key. You need the key to watch protected movies. The (software)players for these movies are able to 'decrypt' these keys from the disc containing the movie. So you already have these keys on the disc. They (the movie companies) just try to hide them from the user (security through obscurity). This is not strange that they use this scheme. It's just the way DRM works on these discs. Due to the lame-ass DMCA law in the United States, it's ILLEGAL to try to find the key on the disc :???: . Somehow a HD-DVD key got discovered (or leaked), and it's going around the great Internet. Several websites have been approached by lawfirms to take the pages down. This key is represented by a hexidecimal code. How the hell is it possible to declare a hexidecimal string illegal?? The same string can also be represented by a different format (e.g. BASE64). Is this also illegal? Since we dont know other hex keys for decrypting copy protected content, every other string of hex codes might also be illegal. Image this; what if the 'next' key might represent the number pi (03 14 15 92 6.....)? Does that mean that all math books need to be burned? Just another example of the fucked up DMCA law in the US. B.t.w. wondering what the last part is of the key... just use Google to search for "09 F9 11 02 9D".... Google knows he rest.

Click to read more ...

'Secure' USB Flashdrives

Recently, the dutch Tweakers website started with dissecting USB flashdrives. Their goal is to see if the so-called secure USB flashdrives are as secure as the manufacturer says they are. They reviewed the SecuStick, and a BioStick. The first protects the data with a password. The latter (two different versions were tested) uses biometrics (fingerprints) to secure your precious data (in combination with AES encryption). The full reports can be read here, (SecuStick) and here (BioStick). The dutch review can be read on the tweakers.net website (here, and here) along with interessting comments on the article. Conclusion of the articles: Some of these so-called secure USB flashdrives are not as secure as you might think. Oke, the data is 'secure' for the casual user. If real secrets (your private pron collection :-) ) are being stored on those USB flashdrives, you might want to consider using TrueCrypt (with a strong password, and keyfiles) to store your 'valuable' data.

Click to read more ...

Getting 'Punished' for Using Pirated Software

Steganos has a piece of software which allows you to create encrypted containers. The Stagenos software is 'freely' available on the P2P networks. just download it and use a key found somewhere on the Internet. This won't help you though.....

You simply install a copy of Steganos Safe 8 but not the new security suite and when doing this you turn "OFF" the update feature temporarily and use a fake serial code you get off the net. Simply mount anyones .SLE file encrypted drive into the software and it will ask you for their password but won't let you in because it's encrypted. From this point you want to turn the "update" feature back on and force steganos to update by right clicking it in your system tray or restarting the software. From this point it will detect you had used a fake or known serial after the update and it will now PUNISH you by resetting your encrypted drives passwords to "123" until you buy a registered copy. [SecurityFocus]

This means that ANYONE is able to open your encrypted content stored in the container. Just use pirated software to open the containers. Thankfully, Truecrypt is still freeware :-) . Too bad it still isn't available for OSX :cry: .

Click to read more ...

TWiT Podcasts Going Off-Topic

I've been a big fan of the TWiT podcasts. Especially the Apple, Windows and security related podcasts. But lately, the content of those podcasts seem to shift to too much off-topic talk. Take the latest edition of Security Now! (Cross-Site-Scripting - Part II). The podcasts is about an hour in length, but the first half hour is nothing but talk about the Sony e-book reader, and favorite writers. What's that got to do with security?? I don't know. Same goes for MacBreak Weekly. It's more about having a good time for the authors, than about bringing some news. I don't mind that the authors are having fun creating the content. Hell, I appreciate a good laugh as much as the next guy, but keep it on topic. Too bad that only about 50% of the content has something to do with the actual title (Mac / Security). If they keep this up, they will loose a listener (not that they might care).

Click to read more ...