> I think e.kabarie is concerned with attacks that would inject bogus CA > certs into the client's cert DB and mark them as trusted. >
Yes! That's exactly the thing... > E.Kabarie: > > The difficulty with your problem statement is that it lacks a threat > model. You seem to suggest that an attacker would have unlimited > access and control to the system under attack. If we are to suppose > that the persons who will be relying on this machine have NO control > over it, and no ability to stop third parties to making any changes > they wish to the system, then of course there is no sense in which > anything we can do can provide those users with security. > Well!!! What if a cracker somehow got access to the files.... Say he got the IP of the sys admin's node while the latter was happily chatting away with him(masquerading as a hazel-eyed blonde.. ;-))... It is not a supremely difficult task to break into a system: we all know that... And considering the value of secret data that SSL often securely communicates, it is worth much more than the needed effort for any mailicious cracker.... Once in, the cracker first cracks the database as I explained, then "hijacks" the victim company's gateway IP(blocking them out & redirecting the incoming traffic to wherever he wants it...) Now he can "securely communicate" with all the company's client's/service providers.... :-)) I'm not much of a security buff; only a novice.... But hope this will come close to a possible threat scenario...!!! > If the attacker can replace or modify any of the DB files upon which > FireFox relies, then the attacker can also replace the FireFox > executables themselves. Any countermeasures we might put into FireFox > could be undone by the attacker simply by replacing the "normal" > FireFox with one that the attacker has modified and built himself. > I never said so... Infact, I had wanted to implement something similar to the browser's security mechanism and had asked for links providing details about the certificate management architecture.... > All the crypto-based security solutions such as SSL and S/MIME exist to > provide security over insecure channels between two users' systems at two > endpoints. The assumption is that each user controls his own system. > SSL and S/MIME are not trying to solve problems where the user's own > system is insecure, but rather are trying to establish secure communications > between two secured systems over an intervening network > that is insecure and may be hostile. At each end of the communications > channel, there must exist a boundary point (or line), formally known as > a security perimeter, such that everything between that point and the user > is known to be controlled by and trustable by the user. The bounary line > separates that with the user can trust from that which is hostile. > > When a user's local computer system is not under his control, and may be > compromised, the user must regard that system as being outside of his > security permiter, part of the insecure and hostile channel through which > his communications may travel. Tamper proof crypto hardware, such as > the devices that Arshad suggested, recognize thatt the security perimeter > may be between the user and his local system. Those security devices > logically exist within the user's perimeter, being something that the user > can control and trust, even when he cannot control and trust his computer > system. > I know what you're talking about... I'm only saying that the certificate database be "DISCREET", not an openly accesible entity.... Arshad did suggest a good way to do so... but I don't wish to force it upon every client to have such an arrangement... I want to sort of ..build it INTO the application... So that the people looking to incorporate "my exploit" 8-) remain at a loss....!! :-) > I think you're trying to devise a means by which the user can trust his > system software and files on a potentially compromised system. That's > simply infeasible on common personal computers today. > > /Nelson Yes!! That's right: we cannot perhaps build a "truly secure" computer... Security is relative to the threat posed...But at some places it might just be enough to not trust even the network admin!!! But what's the fault in trying....?? If the thing is built-in and they don't have the source code.... I can atleast make them work harder for their "prized catch"!!! Reverse engineer the whole thing first, then see if you can crack it...!!!! :-)) Isn't THIS what SSL(any cryptography for that matter...) is based upon...making them work harder for their prize...???? Warm Regards, D3|\||\|!$ _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
