<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>IT Info Magazine &#187; public</title>
	<atom:link href="http://www.itinfomag.com/tag/public/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.itinfomag.com</link>
	<description></description>
	<lastBuildDate>Thu, 02 Feb 2012 08:26:00 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
		<item>
		<title>Code Signing – Part 1</title>
		<link>http://www.itinfomag.com/security-governance/code-signing-%e2%80%93-part-1/</link>
		<comments>http://www.itinfomag.com/security-governance/code-signing-%e2%80%93-part-1/#comments</comments>
		<pubDate>Wed, 02 Nov 2011 08:20:12 +0000</pubDate>
		<dc:creator>George</dc:creator>
				<category><![CDATA[Security Governance]]></category>
		<category><![CDATA[application software]]></category>
		<category><![CDATA[authority]]></category>
		<category><![CDATA[CA]]></category>
		<category><![CDATA[certifciate]]></category>
		<category><![CDATA[code]]></category>
		<category><![CDATA[CRL]]></category>
		<category><![CDATA[key]]></category>
		<category><![CDATA[OCSP]]></category>
		<category><![CDATA[PKI]]></category>
		<category><![CDATA[private]]></category>
		<category><![CDATA[public]]></category>
		<category><![CDATA[Publisher]]></category>
		<category><![CDATA[revocation]]></category>
		<category><![CDATA[signature]]></category>

		<guid isPermaLink="false">http://www.itinfomag.com/?p=1565</guid>
		<description><![CDATA[In application software, code signing is a process used by software publishers (manufacturers) that uses the Public Key Infrastructure (PKI) Technology to create a digital signature based on a private key and the contents of a program file. The resultant signature is then packaged either with the program file or in an associated catalog file. Software manufacturers can either create their own digital certificates, public and private keys using one of the many available free tools or they can purchase a key pair from a trusted certificate authority (CA). In the latter case, the CA will provide them with a digital certificate which is signed by the CA itself. There are different types of code signing certificates and these cater for different software platforms. When a software manufacturer obtains the code signing certificate – also known as Software Publisher Certificate, a programmer within the software house can use it together with the private key to digitally sign files distributed with the software. Briefly, the process of code signing works as follows: A cryptographic hash of the file being signed is created, which is often called a digest The code signing program uses the private key to sign the digest The [...]]]></description>
			<content:encoded><![CDATA[<p>In application software, code signing is a process used by software publishers (manufacturers) that uses the Public Key Infrastructure (PKI) Technology to create a digital signature based on a private key and the contents of a program file. The resultant signature is then packaged either with the program file or in an associated catalog file. Software manufacturers can either create their own digital certificates, public and private keys using one of the many available free tools or they can purchase a key pair from a trusted certificate authority (CA). In the latter case, the CA will provide them with a digital certificate which is signed by the CA itself.</p>
<p>There are different types of code signing certificates and these cater for different software platforms. When a software manufacturer obtains the code signing certificate – also known as Software Publisher Certificate, a programmer within the software house can use it together with the private key to digitally sign files distributed with the software. Briefly, the process of code signing works as follows:</p>
<ol>
<li>A cryptographic hash of the file being signed is created, which is often called a digest</li>
<li>The code signing program uses the private key to sign the digest</li>
<li>The Software Publisher Certificate is transformed into a standardized signed data object and is either embedded into the program file or in a separate file.</li>
</ol>
<p>When end users get the signed program file, they can use the certificate and its associated public key to verify the identity of the file signer and the integrity of the file.</p>
<p>The certificate has links to the CA’s Certification Revocation List (CRL) and if a certificate is known to have become compromised then it will be revoked by the CA by listing it in the CRL list. Users can check whether a certificate is revoked or not, by downloading the CRL list from the links as indicated on the certificate itself, or using a communications protocol called Online Certificate Status Protocol (OCSP) between the client and the CA. The latter is the preferred method nowadays but the former option should be also made available.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.itinfomag.com/security-governance/code-signing-%e2%80%93-part-1/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>When Green Is Bad</title>
		<link>http://www.itinfomag.com/data-backup-recovery/when-green-is-bad/</link>
		<comments>http://www.itinfomag.com/data-backup-recovery/when-green-is-bad/#comments</comments>
		<pubDate>Mon, 05 Jul 2010 02:16:46 +0000</pubDate>
		<dc:creator>chribonn</dc:creator>
				<category><![CDATA[Data Backup & Recovery]]></category>
		<category><![CDATA[disk]]></category>
		<category><![CDATA[EFS]]></category>
		<category><![CDATA[encryption]]></category>
		<category><![CDATA[green]]></category>
		<category><![CDATA[key]]></category>
		<category><![CDATA[Maxtor]]></category>
		<category><![CDATA[private]]></category>
		<category><![CDATA[public]]></category>

		<guid isPermaLink="false">http://www.backupmyhost.com/blog/?p=559</guid>
		<description><![CDATA[A few days ago I received a phone call from a person asking for my services to help him recover data from a failed hard disk. I asked the caller whether he had internet access—sometimes the failed disk takes with it the only available computer. The caller explained that he had internet access and that the patient was a removable disk. I pointed the client to our online questionnaire and asked him to fill in the form. A few minutes later the form arrived. In a nut shell, the disk was a 120GB 3.5” 7200rpm IDE Maxtor drive, two years old. It was housed within an aluminium external drive case. It was hooked up to a standalone Windows XP computer. It was spinning, no unusual noises such as clicks or retry access sounds. The file directory could be read. The client had last successfully placed data on the medium less than 15 days before. I immediately got a hunch about what the problem was. As long as the word “green” didn’t factor in our conversation a chance of success remained. About 30 minutes later the client arrived at our office with the problem disk. I plugged the disk into one [...]]]></description>
			<content:encoded><![CDATA[<p><img class="alignleft size-medium wp-image-563" style="border: 0px;" title="spongebob-squarepants" src="http://www.itinfomag.com/wp-content/uploads/2010/07/spongebob-squarepants.jpg" alt="" width="222" height="165" />A few days ago I received a phone call from a person asking for my services to help him recover data from a failed hard disk. I asked the caller whether he had internet access—sometimes the failed disk takes with it the only available computer. The caller explained that he had internet access and that the patient was a removable disk. I pointed the client to our online questionnaire and asked him to fill in the form. A few minutes later the form arrived.</p>
<p>In a nut shell, the disk was a 120GB 3.5” 7200rpm IDE Maxtor drive, two years old. It was housed within an aluminium external drive case. It was hooked up to a standalone Windows XP computer. It was spinning, no unusual noises such as clicks or retry access sounds. The file directory could be read. The client had last successfully placed data on the medium less than 15 days before.</p>
<p><span id="more-559"></span></p>
<p>I immediately got a hunch about what the problem was. As long as the word “green” didn’t factor in our conversation a chance of success remained. About 30 minutes later the client arrived at our office with the problem disk. I plugged the disk into one of our recovery units, powered it up and a few seconds later was looking at its contents. All file names were in green rather than the usual black font. This meant that the files had been encrypted using Windows XP’s Encrypted File System (EFS). EFS provides a file system level of encryption that allows files to be transparently encrypted from attackers who gain physical access to the computer.  EFS first made its debut in Windows 2000.</p>
<p>I asked the client whether he had reinstalled or replaced the computer on which he had last successfully accessed the data. He replied that this was an old computer and he had donated the machine to his church about 10 days before. I got a negative reply when I asked whether he had ever backed up this computer or made a copy of its encryption keys and certificates.</p>
<p>Have you ever watched a TV program of a high alert situation? That’s what happened next; I explained to the client that his only chance of getting back the data on that drive was if the computer he had donated was still intact. We looked up the church’s phone number and once found (God bless search engines) the client dialled the number. About half a dozen rings someone picked up at the other end. I won’t bore you with the conversation; when the client hung up we had all the details of the person who had volunteered to format the machine and install it from scratch. The second phone call was answered by this person’s mother. She told us that he had brought a computer home a few days ago. From this lead we got the mobile phone of the person my client was so desperately trying to contact.</p>
<p>The client managed to get hold of our make or break person. When asked whether he had formatted the computer the reply was a yes… but using a different hard disk. The hard disk on the original computer was very small and he had decided to replace it with a higher capacity one. The contents of the original hard disk were intact.</p>
<p>A couple of hours later we had rigged the original hard disk within the donated computer and had successfully copied the contents of the data on the external hard disk to unencrypted storage. Without getting too much into the technicalities what follows is a simple explanation of how EFS works. The first time a user enables the EFS, the system automatically generates a public/private key pair for that user if one doesn’t already exist.  This information is held in the user’s profile. For each file / folder, EFS generates a random number and uses the public key to encrypt the file. In order to decrypt the file, the private key is necessary.</p>
<p>Once the private key is lost decrypting the data is impossible.</p>
<p>I would like to thank the client who offered the entire team as well as the chap who had not formatted the hard disk dinner. As he put it “My life depended on that data”. Sadly not all stories end like this.<br />
<!-- ddpostsbyauthor --></p>
]]></content:encoded>
			<wfw:commentRss>http://www.itinfomag.com/data-backup-recovery/when-green-is-bad/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

