On 11/02/2016 19:31, R-D intern wrote:
> Hello ,
> I am a Masters student and currently working on a project related to
> security. I have certain queries regarding ssl security. It would be of
> great use to me if some of my queries get clarified. The following is listed
> as:
> 1. How do I prove that ECC 256 bit key is equivalently strong to RSA 2048
> bit key?
This is so hard that noone has done it yet. Experienced experts
have made estimates based on the best known theoretical attack
against each and comparing the (extreme/impossibly large) amount
of computer power to break them.
For example one of the relevant attacks against 2048 bit RSA is
to use the best known algorithm to factor a 2048 bit number known
to be the multiple of two large primes. This requires a certain
number of fundamental computer resources (CPU cycles and memory
bytes).
A similar consideration can be made for the best algorithm to find
the secret multiplier (private key) from the ECC 256-p point
published as the public key.
Next adjust both numbers by how much those algorithms are going
to improve over the time the private key has to be kept secret
(for SSL/TLS session signatures with ephemeral DH session key
exchange), this is just the time from certificate issuance/key
generation until the certificate expires. But for some other
uses this is the time until signed digital documents (such as
deeds of ownership to a house) are no longer important enough
to protect against forgery, usually many decades.
Especially that last step is very much a matter of opinion,
and thus different researchers disagree. For instance
Certicom, the original main proponents of ECC crypto,
published tables that claimed a much larger RSA key would be
needed to get the same security as 256 bit ECC.
> 2. What all types of threats could be used for testing the above question?
See above.
> 3.The paper has listed Openssl library can be used for enabling ssl
> security , certificate generation and management. I have created an ECC
> certificate that works fine but such a certificate shows "Invalid digital
> signature "message on the certificate. The elliptic curve used for
> certificate generation is one amongst the named curves supported by Openssl
> and recommended by NIST-suite B. How can that be resolved?
Either you did something wrong when generating the certificate,
or you are testing with a software tool that doesn't support
that particular form of ECC signature. Note that ECC keys and
signatures can refer to the chosen curve in one of two ways
("named curve" or explicit curve description), OpenSSL only
accepts the "named curve" form as input.
> 4.The Openssl library has certificate verification method that checks the
> certificate validity w.r.t validity period, certificate chain depth, etc,
> then why is a Certificate Revocation List or an OCSP needed, in a sense if
> the verification is already done, then why should invalid certificates be
> revoked and verification be done on the basis of CRL?
The revocation check is to check if something bad happened after
the certificate was generated and signed by the issuing CA.
Typical examples include:
- The legitimate certificate holder had her private key stolen
("compromised") or at least found herself in a situation where
she could no longer be sure if someone has an illegetimate copy.
- The facts stated in the certificate are no longer true, for
instance, if the certificate states that the certificate holder
is a resident of city X, but has since moved to city Y.
- The CA that issued the certificate finds out it did so in
error, e.g. it accidentally issued it to the wrong person, or it
issued an SHA-1 based certificate after the official deadline
for ceasing all such issuance (This has happened sevaral times
in the last 40 days).
> 5. Is there any other approach for client authentication in SSL other than
> certificates approach?
Yes, the full SSL protocol also supports various password based
methods, but they are considered less secure for most purposes.
> 6. Is ssl security suitable enough for securing connections to server in
> control and monitoring systems? How can client authentication be done for
> such systems using SSL protocol?
Depends how important security of that communication is, and how
strong the minimum SSL settings are configured.
For example if the control connection is for a large industrial
plant of a type where deliberately issuing the wrong control
commands can generate a major disaster (Bopal sized), then as
long as people are living next to the factory or working inside
the factory, it might not be secure to allow such control to be
done from outside the factory, no matter how secure the
connection is (the problem is that the person pushing the buttons
isn't risking his own life too).
But as the potential risks get smaller, the level of security
of the connection can be weighed against the dangers that would
result from compromising the connection. Assessing this
involves not only the technical dangers (how much damage could
someone do), but also how much money and effort someone might
spend to cause that damage deliberately.
At one extreme, the process and its location/ownership may be
such that a major superpower may dedicate some of its top
secret experts to break in. At the other extreme, the
circumstances may make it reasonable to assume no one will
spend more than 1M$ to break into the connection (if the
price of breaking in is less than that, there is a real
risk that ordinary criminals might do it using stolen
tools).
> 7.If CRLs are to be used, then how will the CA know about the private key
> being compromised so that it can revoke the certificate considering it being
> forged?
> Thanks and regards,
> Suman Patro
>
As previously mentioned, the most common ways a certificate
gets added to a revocation list are:
1. The person/company to whom it was issued calls the CA and
says "someone may have stolen my key, please revoke it".
The standard contracts from CAs specify where to call and
how quickly they have to add it to the public revocation
systems.
2. The person/company in whose name it was issued calls the
CA and says "Whomever you issued that certificate to isn't
me, revoke it at once!". Again there are are standard
procedures to do this.
3. A professional review/audit of issued certificates
discovers something should not have been issued and
contacts the CA. Many CAs have internal teams doing such
reviews on a regular basis, and publicly trusted CAs are
subject to independent audits at least once a year.
4. A relevant event (death, bankruptcy, etc.) is announced in
an official medium (such as a national government gazette),
causing the CA to revoke the certificate in accordance with
specific contract clauses regarding said type of event.
5. A relevant event (such as a person getting fired from
their job) is reliably communicated to a CA that issued
a certificate no longer valid then (for instance a
certificate identifying said person as being an authorized
employee).
All in all, these are the same situations in which credit
cards or a door keys might be revoked (mechanical door keys
are revoked by changing the locks).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160211/08e0e296/attachment.html>
