jump to navigation

Email, Meta Data and Non Repudation (“It wasn’t me!”…Shaggy) January 9, 2015

Posted by Chris Mark in Uncategorized.
Tags: , , , , ,
trackback

SilverStarThis is a simple primer on email, authentication and ‘non repudiation.  To understand ‘non repudation’ as it applies to information security, it is important to understand repudiation. Repudiation is simply the act of denying or renouncing something.  A suspect stating that they did not commit a crime is repudiating the crime.  Non-repudiation is a concept in which a “..a party in a dispute cannot repudiate, or refute the validity of a statement or contract”  Within information security this means that a person cannot dispute that he or she was the origin of an action.  We will use email as an example.

Suppose a person (person A) sends an email to another person (person B) in 2011 in which they attach a document including claims to military heroics which resulted in the awarding of some honor..say a Bronze Star.  Later, after it was discovered that person A was not awarded the bronze star and people began to question them Person A decided to disavow any association with said email or reference to the Bronze Star. In short, they have repudiated the claim that they sent the email and created the document.  Person A goes a step further and claims that the document and the email were “forgeries” intended to sully their (Person’ A’s) good name.  Is it possible to demonstrate with a high degree of confidence (or even certainty) that Person A was indeed the originator of the email and the author of the document? YES!  This is where ‘non repudiation’ or the ability to prevent someone from disputing the action is important.

To understand how this can be achieved, there are a few concepts related to email that should be discussed.

1) Authentication– Authentication is is described on wikipedia as:the act of establishing or confirming something (or someone) as authentic, that is, that claims made by or about the subject are true”.  You can read more in an earlier blog post titled Security 101; Authentication.  Authentication is an important part of access control and email.  Email access control is managed by two components.  1) the user who is assigned a username and 2) the password or other authentication mechanism used to ‘authenticate’ to the system.  By using the correct password that is only known to the user, the system ‘authenticates’ their access and allows them to access the email. The rigor of the authentication provides greater confidence that the person is the originator of the email.  While ‘multi factor’ authentication provides the greatest confidence, a password also provides very strong non-repudiation for most purposes. 

2) Passwords – Understanding that the username and password are assigned to control access to an email account, Person A could conceptually make the claim that the password was ‘hacked’ and by discovering the password, Person B would be able to masquerade as Person A and send fraudulent emails.  Is this possible?  After reading, you decide.  Passwords are (almost without exception) stored using a one way cryptographic function known as a hash.  You can read more about hashes in my previous blog post here.  In short, a ‘hash’ is not encryption in that cannot be ‘reversed’ and the original data cannot be derived. (for those techies, this post does not discuss advanced methods).  When a person first creates a password they type the password into the system and the system ‘hashes’ the password using some algorythm (SHA 256, MD5 etc.) and stores the hash value of the password.  The system does not know what your password is nor does it care. All it knows is that IF you enter the correct password to access the account, the hashes will match and you are given access.  This is why email administrators CANNOT tell you your password. All they can do is ‘reset’ the password if you are locked out.  There is no feasible way for anyone to derive the password from a hash.

3) Email administration – In email systems with multiple users an ‘administrator’ is assigned. This administrator can add and delete users and reset passwords. In most commercial email systems that host email, domains, and websites (Register.com, BlueHost, Network Solution, etc) the user can be forced to change the password upon initial login (strongest method) or the user’s are, at the least, given the ability to change their password.  Irrespective of anything a person would need administrative rights to the email system to reset or change a password.  Keep in mind that the administrator cannot ‘retrieve’ the password, rather can only ‘reset’ the password.

Scenario proposed by Person A – Person A contents that Person B ‘hacked’ their email account.  Clearly what they mean was the administrator account was ‘hacked’ or somehow accessed to give access to Person B’s email, in which a fraudulent message was sent to Person B (the same person).  Assuming this is true, Person B would NOT have access to Person A’s password (see #1, 2 above) and would only have the ability to ‘reset’ the password.  Once reset, Person B could then log into the system as Person A and send the forged email.  Here is the problem with such a scenario.  Remember that the Admin cannot ‘retrieve’ Person A’s password.  If the password was ‘reset’ Person A would not longer have access to their own email.  This should send up red flags that something is amiss!…So Person A believes that Person B simply changed the password back to the original password to keep from being identified.  That scoundrel!  Fortunately, this cannot happen.  As discussed in #2 above, the password cannot be retrieved from the Hash so IF Person B were to ‘reset’ the password for Person A, they could not then reset the password to the original.  Again, Person A would have no access to their email and this should be a major red flag.

So how else can we determine the origin of an email?  There are numerous ways including the information contained in the Header.  You can read more about email Header’s here.  Email headers contain a ton of valuable information including the IP from which the email was sent, the servers over which it was transferred, who sent it, who received it and various time stamps.  These are all managed for ‘integrity’ to support ‘non repudiation.  While the ‘header’ could be modified by a person who has ‘downloaded’ the email, if that person (Person B, for example) was savvy, they would ensure that the original email was retained on a trusted, third party email service.  This would allow a forensic investigation to validate the integrity of said email and its contents.

How can someone validate the origin of a document contained in said email?  Person A claims that not only was the email forged but that the attached document claiming military heroics was also forged.  AHAA!  How can the document be validated?  Unless Person A was using specialized software to ‘sanitize’ the document before attaching the document contains ‘hidden’ data known as Meta Data. You can learn more about Meta data here. Some of the types of metadata that may be stored along with your saved office documents can include your name, initials, company name, computer name, the disk or network server the file was stored in, file properties, revisions, hidden text, deleted comments,  and so much more. Microsoft Office documents are frequently passed among co-workers, clients and contractors, so when the documents are shared, quite often, so is large amounts of metadata”  

So, if Person A did not safe the document in a ‘sanitized format’ it is possible to see that Person A, using Computer A, on 6/13/11 at 7:20 PM created the document in question….as an example…When coupled with the email headers stored with the original email at a secure, third party service, the meta data provides additional evidence to support the originator of the email and the document.  

This is an example of who non repudiation can work.

Comments»

No comments yet — be the first.

Leave a comment