protecting objects from being changed

[Andy B]

Is there a way that is already built into .net 3.5 that will let me protect
an object from being modified when the object is public?

 

[Jon Skeet [C# MVP]]

Is there a way that is already built into .net 3.5 that will let me protect
an object from being modified when the object is public?

Simply put: don't expose any way of making any changes. Make all your
properties readonly and make sure your methods don't change anything.
Making all member variables readonly goes some way to doing this,
although it's less clearcut if one of your member variables is of a
mutable type itself (e.g. StringBuilder).

It's unfortunate that C# doesn't have more support for creating and
checking immutable types - I know it's something that the design team
are considering for a future version.

Jon

 

[Andy B]

I have an object that when it's IsSigned property is set to bit 1, can't be
changed. Otherwise if it is set to 0, it can be changed in whatever way is
needed. This check would need to be done before putting the object inside a
database and after it is pulled out of the database as well. The object will
be serialized into an xml format and it's IsSigned state will be put into a
database table column seperate from the object itself. I.e. in the table
called objects, I would have the columns Id, IsSigned, IsFulfilled, IsPaid,
Object. I guess I'm just looking for some easier way of doing something like
this since the object already has over 60 public properties built into it.
These 60+ properties are split between 18 sub classes and data types.

 

[Andy B]

If that state is part of the object, why doesn't it get stored with the

rest of the object?

Good question. I never did think about doing that - Just serialize the
object states into xml with the rest of it. I will have to consider
something like that. Guess figuring things out can be kind of hard when you
have a large project to get done.

As far as the mutability issue goes, I hope you see why your question
didn't really describe what you're trying to do. As long as the object is
an object, you have the ability in your own code to prevent any changes
from being made to the object when it's "signed". That much would be
simple.

I am trying to figure out the different ways of making an object
unchangeable. Guess the original question didn't really help with what I
needed though...

As soon as the object is serialized, it's no longer an instance of your
actual object, and you have no control over that data (other than whatever
normal control >mechanisms might exist...these would not be particular to
.NET though).

The object would be serialized into an XmlDocument object and then given to
the business/validation layer of the code. It would then get validated and
given to the data access flow and then dumped into the database. The reverse
(of course) would be for getting the object out of the database: Pull it out
of the database, give it to the business/validation layer, validated (and
whatever else needed to be done), convert the columns and its contents into
c# data types and then hand them off to the top layer code. Don't think this
has anything to do with your last section, but figured it was relevant.

For what it's worth, it seems to me that if your object really is
"signed", then that means you've use some sort of crypto technique to sign
the object. If you've >done it in a valid way, then it should actually be
impossible to change the data of the object when it's externalized.

I considered using some sort of encrypting format to prove signing, Any
ideas on what to use and how to use it? What do you mean if it is done in a
valid way? The signing or the encrypting? I am assuming that externalizing
the object means to make it available outside the intended environment it is
supposed to be used in (like an xml file for example)?

For example, if you encrypt the object's data as stored in the database,
or at least the data that's important to you with respect to not being
changed, then >outsiders could not modify the object.

That's what I figured in the last section.

Of course, once you start down that road, you run into the usual computer
security issues. A particular problem is that unless you have complete
control over the >execution environment of your code, you have no way to
ensure that it won't be reverse engineered in order to get the encryption
key. That's literally an >impossible problem to solve.

Oh, yea. Security issues are always fun. NOT! On the note of security, In
order to access the serialized objects that are inside the database, there
will have to be some user authentication in place. I have some ideas to try
and keep the security keys and stuff to a low minimum, but I'm pretty sure a
pro hacker would be able to figure anything out. I might not be able to use
the ideas in full, but do you have any good security tips and stuff when it
comes to authentication?

Perhaps you could be more clear about what your actual goal is. Lots of
applications get by without any strong guarantee that the data can't be
modified. When >the data is modified, it usually manifests itself as
simply a case where the user can change the data behind the program's back,
or the data winds up being >invalidated. These are usually acceptable
outcomes.

This is a series of web applications that will use the objects in question.
I have to write a document signing service for customers to be able to sign
the documents (objects) in question. This document signing service needs to
comply with the ELECTRONIC SIGNATURES IN GLOBAL AND NATIONAL COMMERCE ACT
(www.ftc.gov/os/2001/06/esign7.htm). Just invalidating the object, or
letting somebody be able to change the data behind the programs back can't
be allowed. For every one's sake, the objects (documents) have to be as
secured as possible. This means doing whatever possible to make sure that
once the document is signed, that it can't be changed in any way except for
setting state bits on it like paid in full or fulfilled in the case of a
contract. There would have to be user authentication (like mentioned above)
where only the person that signed the document can see it. This is the very
basic plan. It is more complex than this - but for security reasons, I can't
say any more about the service design.

It would help to answer your question if you could be more clear about why
it is you need this functionality, what you expect to gain from it, and to
what extent >do you need any guarantees as to the success of this
strategy. If you could also explain what "signed" means in this context,
that would be helpful (inasmuch as it >doesn't seem to fit the usual
meaning, since if it did, you wouldn't be asking the question ).

See above for project explanation to the best of my legal ability.

 

[Andy B]

Do you have a link to the pgp encryption stuff? And I forgot to mention,
there are 2 different people signing the document (the company and the
customer).

[...]
The object would be serialized into an XmlDocument object and then given
to
the business/validation layer of the code.

As soon as that happens, you lose control of the object per se. Even in
your own object class, there's not really anything you can do from a C#
point of view to ensure that the object doesn't change. C# provides
mechanisms, as mentioned earlier in the thread, to prevent regular .NET
code from modifying the object. But users can always get at the object
via reflection, and will always be able to modify members of the class
instances that way.

[...]
I considered using some sort of encrypting format to prove signing, Any
ideas on what to use and how to use it? What do you mean if it is done
in a
valid way? The signing or the encrypting?

Well, both. But I was mainly referring to the signing. I take as granted
that if you're going to use encryption, you'll take the time to learn how
to do it right. In the context of computer documents, "signing" has a
very specific meaning. For it to be valid, it has to ensure that the
document hasn't been modified (except possibly by the owner of the
signature).

I am assuming that externalizing
the object means to make it available outside the intended environment
it is
supposed to be used in (like an xml file for example)?

Yes, that's what I meant.

[...]
Oh, yea. Security issues are always fun. NOT! On the note of security, In
order to access the serialized objects that are inside the database,
there
will have to be some user authentication in place. I have some ideas to
try
and keep the security keys and stuff to a low minimum, but I'm pretty
sure a
pro hacker would be able to figure anything out. I might not be able to
use
the ideas in full, but do you have any good security tips and stuff when
it
comes to authentication?

No, not really. I don't have enough experience in that area to say that I
can offer anything other than the basics. And if you've given this
problem any thought at all, there's a good possibility you already know
whatever I might mention.

Just in case though, I'll point out that user authentication only address
signing in a strong way if there is some encrypted data available only to
authenticated users that's involved in the signing. That is, it's well
and good to have user authentication, but you have to keep in mind that
there are other routes to the data than going through an authenticated
user. The data itself needs to be protected.

As an example, the NTFS file system includes a security model that allows
you to define access rights to a file based on the user. However, this is
entirely enforced by Windows. There's no requirement that something
reading the file system obey those access rights, and in fact I know of at
least one NTFS implementation that doesn't. So Windows addresses this by
allowing users to also encrypt files. Windows uses the user's password
somehow (I don't know the specifics), and so only users that have provided
that password can decrypt the data.

Depending on your needs, you don't have to encrypt _all_ of the data. But
you do need to use some sort of encryption of data that's tied to the
document contents. See PGP for an example of that.

This is a series of web applications that will use the objects in
question.
I have to write a document signing service for customers to be able to
sign
the documents (objects) in question. This document signing service needs
to
comply with the ELECTRONIC SIGNATURES IN GLOBAL AND NATIONAL COMMERCE ACT
(www.ftc.gov/os/2001/06/esign7.htm).

I took a quick look at the link. For what it's worth, I didn't see
anything that looked like specific standards to which you would comply.
Did I miss something? The document looks more like a description as to
the who and why of document signing, and includes some sort of agenda for
a conference in which those issues are discussed.

Just invalidating the object, or
letting somebody be able to change the data behind the programs back
can't
be allowed. For every one's sake, the objects (documents) have to be as
secured as possible. This means doing whatever possible to make sure that
once the document is signed, that it can't be changed in any way except
for
setting state bits on it like paid in full or fulfilled in the case of a
contract. There would have to be user authentication (like mentioned
above)
where only the person that signed the document can see it. This is the
very
basic plan. It is more complex than this - but for security reasons, I
can't
say any more about the service design.

Assuming that part of the design is to ensure that only the signing user
can see the document, then I think you're looking at encrypting the entire
document. Especially if you intend to comply with any sort of industry
standards with respect to document signing.

If you wanted to support signing in a way that allowed non-signing users
to see the document, then an alternative would be to follow the PGP
model. Then the document could be assured of not having changed, without
having the whole thing encrypted.

In either case, this isn't something that's going to be supported in the
language. .NET provides cryptograpic classes in a specific namespace;
those might be useful in your implementation, but they are only going to
be tools. As far as I know, there's no magic bullet that you can use that
will just enable this sort of thing.

If it's okay for the document to be vulnerable except as stored in the
database, I suppose it's possible that you can use some sort of database
implementation that supports user-authenticated encryption (e.g. similar
to the encryption Windows includes on NTFS). I've never heard of that,
but then I don't really know that much about specific database
implementations. The fact that I've never heard of it has no bearing on
the likelihood of it existing.

Pete

 

[stv.dmsk]

Good question. I never did think about doing that - Just serialize the
object states into xml with the rest of it. I will have to consider
something like that. Guess figuring things out can be kind of hard when you
have a large project to get done.


I am trying to figure out the different ways of making an object
unchangeable. Guess the original question didn't really help with what I
needed though...


The object would be serialized into an XmlDocument object and then given to
the business/validation layer of the code. It would then get validated and
given to the data access flow and then dumped into the database. The reverse
(of course) would be for getting the object out of the database: Pull it out
of the database, give it to the business/validation layer, validated (and
whatever else needed to be done), convert the columns and its contents into
c# data types and then hand them off to the top layer code. Don't think this
has anything to do with your last section, but figured it was relevant.


I considered using some sort of encrypting format to prove signing, Any
ideas on what to use and how to use it? What do you mean if it is done in a
valid way? The signing or the encrypting? I am assuming that externalizing
the object means to make it available outside the intended environment it is
supposed to be used in (like an xml file for example)?


That's what I figured in the last section.


Oh, yea. Security issues are always fun. NOT! On the note of security, In
order to access the serialized objects that are inside the database, there
will have to be some userauthenticationin place. I have some ideas to try
and keep the security keys and stuff to a low minimum, but I'm pretty surea
pro hacker would be able to figure anything out. I might not be able to use
the ideas in full, but do you have any good security tips and stuff when it
comes toauthentication?


This is a series of web applications that will use the objects in question..
I have to write a document signing service for customers to be able to sign
the documents (objects) in question. This document signing service needs to
comply with the ELECTRONIC SIGNATURES IN GLOBAL AND NATIONAL COMMERCE ACT
(www.ftc.gov/os/2001/06/esign7.htm). Just invalidating the object, or
letting somebody be able to change the data behind the programs back can't
be allowed. For every one's sake, the objects (documents) have to be as
secured as possible. This means doing whatever possible to make sure that
once the document is signed, that it can't be changed in any way except for
setting state bits on it like paid in full or fulfilled in the case of a
contract. There would have to be userauthentication(like mentioned above)
where only the person that signed the document can see it. This is the very
basic plan. It is more complex than this - but for security reasons, I can't
say any more about the service design.


See above for project explanation to the best of my legal ability.

For authentication, you may want to chack this product out:
http://www.visual-guard.com/EN/.net...ment-access-control-authentication-tool#admin

Do you need to have authorization as well?

 

[Andy B]

Yup...it needs authorization as well..

Good question. I never did think about doing that - Just serialize the
object states into xml with the rest of it. I will have to consider
something like that. Guess figuring things out can be kind of hard when
you
have a large project to get done.


I am trying to figure out the different ways of making an object
unchangeable. Guess the original question didn't really help with what I
needed though...


The object would be serialized into an XmlDocument object and then given
to
the business/validation layer of the code. It would then get validated and
given to the data access flow and then dumped into the database. The
reverse
(of course) would be for getting the object out of the database: Pull it
out
of the database, give it to the business/validation layer, validated (and
whatever else needed to be done), convert the columns and its contents
into
c# data types and then hand them off to the top layer code. Don't think
this
has anything to do with your last section, but figured it was relevant.


I considered using some sort of encrypting format to prove signing, Any
ideas on what to use and how to use it? What do you mean if it is done in
a
valid way? The signing or the encrypting? I am assuming that externalizing
the object means to make it available outside the intended environment it
is
supposed to be used in (like an xml file for example)?


That's what I figured in the last section.


Oh, yea. Security issues are always fun. NOT! On the note of security, In
order to access the serialized objects that are inside the database, there
will have to be some userauthenticationin place. I have some ideas to try
and keep the security keys and stuff to a low minimum, but I'm pretty sure
a
pro hacker would be able to figure anything out. I might not be able to
use
the ideas in full, but do you have any good security tips and stuff when
it
comes toauthentication?


This is a series of web applications that will use the objects in
question.
I have to write a document signing service for customers to be able to
sign
the documents (objects) in question. This document signing service needs
to
comply with the ELECTRONIC SIGNATURES IN GLOBAL AND NATIONAL COMMERCE ACT
(www.ftc.gov/os/2001/06/esign7.htm). Just invalidating the object, or
letting somebody be able to change the data behind the programs back can't
be allowed. For every one's sake, the objects (documents) have to be as
secured as possible. This means doing whatever possible to make sure that
once the document is signed, that it can't be changed in any way except
for
setting state bits on it like paid in full or fulfilled in the case of a
contract. There would have to be userauthentication(like mentioned above)
where only the person that signed the document can see it. This is the
very
basic plan. It is more complex than this - but for security reasons, I
can't
say any more about the service design.


See above for project explanation to the best of my legal ability.

For authentication, you may want to chack this product out:
http://www.visual-guard.com/EN/.net...ment-access-control-authentication-tool#admin

Do you need to have authorization as well?

 

[Andy B]

I'm not sure I understand the "2 different people signing the document".

You're not specific about what effect this should have, or how you expect
the two to >interact.

The company and the customer are supposed to sign the document. When the
form is filled out by the company online, a username and an encryption key
(a password as the customer would know it) is sent to the customer. They are
directed to login, view and sign the document (which has already been signed
by the company). After the company signs and presents the document for the
customer to sign,, for some reason the customer needs some changes made to
the document (the "form attached to the document"), the company should be
able to make the changes to satisfy the customers changes to the "form" and
then present it back to the user for signing. I think this possibly might be
a legal issue though since the standars for e-signing act of US law states
that after signing the document, it should be checked to make sure it can't
be changed. Is this before both people sign, or after both people sign?

Are both people supposed to be able to access the document after it's been
signed?

Yes, both customer and company have to be able to view the document. There
might be a slight issue though. When the company fills out the document,
they have to sign it before it is presented to the customer before the
customer signs it. So, basically, even though the company has already signed
the document and commited to provide the services outlined in the document,
the customer still must be able to view and sign it for themselves. We
already found that 2 encryption keys for each document would be required -
one for customer and one for company.

Can you simply store two encrypted versions of the document?

No, this method is not possible. Disk space is expensive and the database
needs to be as small as possible. Each transaction (document signing) will
roughly take about 2-3k in size. So, there can only be 1 copy of the
document for each transaction.

Alternatively, is it okay for the company to retain a copy of the
customer's encryption key?

Yes, that is entirely possible. The only restriction to this is that if the
customer forgets or loses their security key (password), it can't be
retrieved or reset. The conciquences to losing or forgetting the security
key is that the customer will not be able to view their signed documents
again (since most security signing services or programming addins do the
same sort of thing).