Federal ID: The "Real-ID" ?

There has to be some sort of system to transmit the private key (stored in the database at a remote location) to the ID reader, which then uses the public key to decrypt it. This transmission - which will occur millions of times daily - opens up the Man in the Middle attack as well as other lines of attack.

Quote:

There has to be some sort of system to transmit the private key (stored in the database at a remote location) to the ID reader, which then uses the public key to decrypt it. This transmission - which will occur millions of times daily - opens up the Man in the Middle attack as well as other lines of attack.

This is simply wrong.

The whole idea of assymetric encryption is that the reader only needs the public key. Only the writer needs the private key (which will open up some problems).

A Man in the Middle attack is very easy to design a counter to. You just need a trusted third party. Commericial systems use certificates for just this reason... and the open source ecryption uses the "Web of Trust". These techniques work just fine.

I really don't think you know what you are talking about.

Quote:

There has to be some sort of system to transmit the private key (stored in the database at a remote location) to the ID reader, which then uses the public key to decrypt it. This transmission - which will occur millions of times daily - opens up the Man in the Middle attack as well as other lines of attack.

This is simply wrong.

The whole idea of assymetric encryption is that the reader only needs the public key. Only the writer needs the private key.

A Man in the Middle attack is very easy to design a counter to. You just need a trusted third party. Commericial systems use certificates for just this reason... and the open source encryption uses the "Web of Trust". These techniques work just fine.

I really don't think you know what you are talking about.

ebrown_p wrote:

Quote:

There has to be some sort of system to transmit the private key (stored in the database at a remote location) to the ID reader, which then uses the public key to decrypt it. This transmission - which will occur millions of times daily - opens up the Man in the Middle attack as well as other lines of attack.

This is simply wrong.

The whole idea of assymetric encryption is that the reader only needs the public key. Only the writer needs the private key (which will open up some problems).

A Man in the Middle attack is very easy to design a counter to. You just need a trusted third party. Commericial systems use certificates for just this reason... and the open source ecryption uses the "Web of Trust". These techniques work just fine.

I really don't think you know what you are talking about.

Sorry, I appear to be confused as to how this system works.

What information is encrypted on the ID itself - the private key?

What happens if my information changes - do I need a whole new ID made from the central authority?

You say "(which will open up some problems)." What happens to all the IDs out there if the private key gets revealed, something which there would be a tremendous incentive for an unscrupulous and poor govt' employee to do?

Who will be the 'trusted third party?' If I understand the Web of Trust right.

There seem to be many more ways that this system could be wrecked then just straight hacking the code - though I don't believe that such a thing is impossible nor will be impossible in the future.

Cycloptichorn

The problem here is that you don't understand how the encryption is done.

And I'm not terribly sure you know what hacking is either.

You can't "hack" code remotely.

You can hack a system by finding a defect in security measures, but that's about it.

To hack the code itself, you have to either patch it or make changes and recompile. You could possibly come up with a scheme to use a virus to patch an executable, but with the security that would accompany this system, that is unlikely.

It doesn't need secure hardware.

The encryption and all isn't the point.

In truth, the data doesn't need to be encrypted. We can store an identifier on the card and that along with maybe a pin number could be sent to the server for a "go or no-go". The government already has the data, and there's no way to "track" anyone moving around any more than there already is.

Quote:

The problem here is that you don't understand how the encryption is done.

Wrong[/quote

Obviously I'm right, as you admited it a few posts ago AND demonstrated that you don't know what a trusted party was in the case of PKI.

[quote]

Quote:

And I'm not terribly sure you know what hacking is either.

Also wrong

Quote:

You can't "hack" code remotely.

I never claimed you could. You hack code through brute force attacks and through looking for errors in the system. Neither is a remote function.

Quote:

You can hack a system by finding a defect in security measures, but that's about it.

Um, yeah, thanks for the tip.

Quote:

To hack the code itself, you have to either patch it or make changes and recompile. You could possibly come up with a scheme to use a virus to patch an executable, but with the security that would accompany this system, that is unlikely.

Really?

Who provides that security? Who maintains that security? How much will that cost?

You say:

Quote:

It doesn't need secure hardware.

If the hardware isn't secure, then it's useless.

If the software isn't secure, it's useless.

If the method of information transmission isn't secure, it's useless.

You seem to be glossing over some of the security flaws inherent within such a system.

You postulate a system - one which would be under constant attack, given the nature of what we're talking about - which is more secure than any other widely-used system that exists today. I find this to be a rather uncompelling argument.

I also agree with earlier arguments about inherent privacy for citizens, and find suggestions that the gov't wouldn't load up as much information as possible onto such a card to be, well, laughably naive

Cycloptichorn

Quote:

The encryption and all isn't the point.

Without the encryption, making a fake card is a snap. So I think it's accurate to say that yes, the encryption IS the point.

Quote:

In truth, the data doesn't need to be encrypted. We can store an identifier on the card and that along with maybe a pin number could be sent to the server for a "go or no-go". The government already has the data, and there's no way to "track" anyone moving around any more than there already is.

Situation:

Data on my card, which has an encrypted signiature but the data is as you say unencrypted.

I copy all the information to a new card, but change the data which is unencrypted while keeping the signiature the same. Therefore, even though the database will say I have green eyes, the new me will have blue eyes. The information transmission is one-way, so how will the gov't know I'm using a fake card - and how will anyone else?

I'm open to the possibility that these questions have been answered, so if they have, please tell me the answers for them.

Cycloptichorn

Cycloptichorn wrote:

Quote:

The encryption and all isn't the point.

Without the encryption, making a fake card is a snap. So I think it's accurate to say that yes, the encryption IS the point.

Quote:

In truth, the data doesn't need to be encrypted. We can store an identifier on the card and that along with maybe a pin number could be sent to the server for a "go or no-go". The government already has the data, and there's no way to "track" anyone moving around any more than there already is.

Situation:

Data on my card, which has an encrypted signiature but the data is as you say unencrypted.

I copy all the information to a new card, but change the data which is unencrypted while keeping the signiature the same. Therefore, even though the database will say I have green eyes, the new me will have blue eyes. The information transmission is one-way, so how will the gov't know I'm using a fake card - and how will anyone else?

I'm open to the possibility that these questions have been answered, so if they have, please tell me the answers for them.

Cycloptichorn

Excuse my language, but you are a **** retard. The entire POINT of a digital signature is that THE DATA CANNOT BE CHANGED BECAUSE THE SIGNATURE WOULD THEN BE INVALID!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

n truth, the data doesn't need to be encrypted.

It makes perfect sense, if you understand what a digital signature is. And yes, I'm losing my temper because you insist on aruging about this when you obviously have no clue as to the technologies employed. Just take a few minutes and read up on digital signatures. Hell, I even posted an article a few pages back that tells you how the new passports were copied. BUT it also explains that because of the signature, it still will not authenticate.

Thank you! That's one of the first rules of cryptography - that keys are NEVER trasmitted in their original state. For gee-whiz... even passwords that you send over the net or nearly anywhere else are not stored on the server and are never actually sent to that server. There is an algorithm called a hash that is run on the password and then the result is sent. The has is very complex and like asymmetic encryption, it cannot be reversed mathematically. So once your password is hashed, no one can figure out the original password.

Hardware will always be exposed to possible tampering, but it is much more difficult to alter hardware.

Yes, many public keys can be generated from a single private key.

Everyone's info could be decrypted from the singular private key, in theory. However, in a scheme this large, it would be nearly impossibly to use a single private key. There would undoubtdely be many and so if one or two are compromised, it wouldn't expose everyone to risk.

The ID card itself probably wouldn't carry very much information, but it would access relevant databases. Probably only thing transmitted would be that you are who you say you are. That individual identity would be compared with information contained in existing data banks. The return data would give information relevant to the query. lf you buying a firearm, the system would check to see if you were a convicted felon, mentally disturbed, etc., and then would note where and when the query was made. I doubt that the system would do more than make information available on which a local decision would be made. The number of citizen files and the size of the data available is in itself a guarantee that no Big Brother is likely to abuse the system. There is, of course some risk to such a system being in general use, but the up side is that terrorists and criminals would find it much harder to lose themselves in the system. The system might guarantee the prompt delivery of your medical records in an emergency, or confirm one's eligibility for any number of social services.