One related technology that seems to have taken hold is tokenization. A user has a credit card number that needs to be protected. So a system will instead use a token for the duration of the session. The token is a 64-bit number that is used in lieu of the credit card number.
So what are some other factors inhibiting the adoption of encryption? There is no clear standard for systems to work with each other. The Oasis group is working on KMIP (Key Management Interoperability Protocol). And the IEE is pitching P1619. The authors of the article I read were hopefully that Microsoft would lead the way with their Active Directory. Good luck with that.
- employees had to be fingerprinted
- all data sent must be encrypted
- data sitting around needed sharding
- access to data had to be limited
It is difficult to convince a customer that the cloud is secure. The technology is relatively new. There are no standards. The act of adding encryption slows things down.
You know the hackers are going to want to target cloud repositories. There is potentially a lot of corporate data out there waiting to be stolen. I do not know enough about Cloud Computing to determine whether the thing is secure enough for my trust.
PKCS #10 defines the syntax or format of a request to a certificate authority. PKCS #11 is Cryptoki (crypto key). This is a hardware solution like using smart cards for authentication.
PKCS #12 defines how users can share private keys. PKCS #13 is the advanced topic of elliptical curves. I am not an expert in the technology. From a distance it looks like a lot of math.
PKCS #14 defines a pseudo random number generator. Generating true random numbers is difficult. Finally PKCS #15 covers tokens. That is PKCS in a nutshell. Although it goes up to PKCS #15, there are only 13 distinct parts as #2 and #4 are rolled into the standard for PKCS #1.
Next time I plan to get deep into keys. Stay tuned.
What I found very interesting were the details of a bunch of time activated scripts this guy left behind at Fannie Mae. His first act was to add some code to the end of a daily script. This code would retrieve and install a bunch of other scripts.
Here is an example of what of the payload scripts did. It would generate a list of servers in the company. Then it would disable monitoring. Finally it would disable the ability to log into all the servers that it found. Well that is bad, but is not too evil.
Next the terminated contractor wrote a script that would clear server logs. Then it would remove root access to machines and delete the data on them. Finally it would shut down the servers automatically.
The last script was especially evil. It would attempt to corrupt any systems it could find in the company. Then it would go after the backup machine, clear out the backups, and turn them off. This hacker was just plain thorough.
Luckily another engineer detected the original script that was to install all the other rogue code. Upon detection, he shut everything down in the company until they could figure out what was going on. That was the one smart move the company made. These rogue scripts could have done severe damage to the bank.
Props to The Inquirer for providing the facts for this blog post.
SAML stands for Security Assertion Markup Language. It is based on XML. You can tell from the name. SAML is used for authentication between domains. For practical purposes, it helps implement single sign on. You type in your user name and password once. Then you can go everywhere and be automatically authenticated. You do not have to retype in your credentials.
CAS stands for Code Access Security. It is part of the .NET framework. CAS prevents untrusted code from executing privileged instructions. An administrator sets up the security policy for your machine. The .NET common language run time (CLR) then maps programs to code groups. These code groups have permissions set. The CLR then either allows or disallows the instructions to execute.
STS is the Security Token Service. A client wants to access a web service. The client first gets a token from an STS server. Then the client passes the token to the web service. The web service validates the token against the STS. Finally the web service honors the client request if the token checks out with the STS.
PKCS #1 is encryption using the RSA algorithm. PKCS #3 uses the Diffie-Hellman algorithms. It is how you exchange a key between two people. PKCS #5 covers passwords.
PKCS #6 is the extended certificate syntax. It describes the extra information like e-mail addresses within certificates. PKCS #7 covers the use of envelopes. An example is S/MIME.
PKCS #8 is for private key encryption. I will cover PKCS 9 through 15 next time around. Be ready for things such as Cryptoki.