<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/02/2016 19:31, R-D intern wrote:<br>
</div>
<blockquote class=" cite"
id="mid_1455215478519_63504_post_n7_nabble_com"
cite="mid:1455215478519-63504.post@n7.nabble.com" type="cite">
<pre wrap="">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?</pre>
</blockquote>
<tt>This is so hard that noone has done it yet. Experienced experts
<br>
have made estimates based on the best known theoretical attack <br>
against each and comparing the (extreme/impossibly large) amount <br>
of computer power to break them.</tt><tt><br>
<br>
For example one of the relevant attacks against 2048 bit RSA is <br>
to use the best known algorithm to factor a 2048 bit number known
<br>
to be the multiple of two large primes. This requires a certain <br>
number of fundamental computer resources (CPU cycles and memory <br>
bytes).<br>
<br>
A similar consideration can be made for the best algorithm to find<br>
the secret multiplier (private key) from the ECC 256-p point <br>
published as the public key.<br>
<br>
Next adjust both numbers by how much those algorithms are going <br>
to improve over the time the private key has to be kept secret <br>
(for SSL/TLS session signatures with ephemeral DH session key <br>
exchange), this is just the time from certificate issuance/key <br>
generation until the certificate expires. But for some other <br>
uses this is the time until signed digital documents (such as <br>
deeds of ownership to a house) are no longer important enough <br>
to protect against forgery, usually many decades.<br>
</tt><br>
<tt>Especially that last step is very much a matter of opinion, <br>
and thus different researchers disagree. For instance <br>
Certicom, the original main proponents of ECC crypto, <br>
published tables that claimed a much larger RSA key would be <br>
needed to get the same security as 256 bit ECC. </tt><br>
<br>
<blockquote class=" cite"
id="mid_1455215478519_63504_post_n7_nabble_com"
cite="mid:1455215478519-63504.post@n7.nabble.com" type="cite">
<pre wrap="">
2. What all types of threats could be used for testing the above question?</pre>
</blockquote>
<tt>See above.</tt><br>
<blockquote class=" cite"
id="mid_1455215478519_63504_post_n7_nabble_com"
cite="mid:1455215478519-63504.post@n7.nabble.com" type="cite">
<pre wrap="">
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?</pre>
</blockquote>
<tt>Either you did something wrong when generating the certificate,
<br>
or you are testing with a software tool that doesn't support <br>
that particular form of ECC signature. Note that ECC keys and <br>
signatures can refer to the chosen curve in one of two ways <br>
("named curve" or explicit curve description), OpenSSL only <br>
accepts the "named curve" form as input.<br>
<br>
</tt><br>
<blockquote class=" cite"
id="mid_1455215478519_63504_post_n7_nabble_com"
cite="mid:1455215478519-63504.post@n7.nabble.com" type="cite">
<pre wrap="">
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?</pre>
</blockquote>
<tt>The revocation check is to check if something bad happened after
<br>
the certificate was generated and signed by the issuing CA.<br>
<br>
Typical examples include:<br>
<br>
- The legitimate certificate holder had her private key stolen <br>
("compromised") or at least found herself in a situation where <br>
she could no longer be sure if someone has an illegetimate copy.<br>
<br>
- The facts stated in the certificate are no longer true, for <br>
instance, if the certificate states that the certificate holder <br>
is a resident of city X, but has since moved to city Y.<br>
<br>
- The CA that issued the certificate finds out it did so in <br>
error, e.g. it accidentally issued it to the wrong person, or it<br>
issued an SHA-1 based certificate after the official deadline <br>
for ceasing all such issuance (This has happened sevaral times <br>
in the last 40 days).<br>
</tt><br>
<blockquote class=" cite"
id="mid_1455215478519_63504_post_n7_nabble_com"
cite="mid:1455215478519-63504.post@n7.nabble.com" type="cite">
<pre wrap="">
5. Is there any other approach for client authentication in SSL other than
certificates approach?</pre>
</blockquote>
<tt>Yes, the full SSL protocol also supports various password based
<br>
methods, but they are considered less secure for most purposes.</tt><br>
<blockquote class=" cite"
id="mid_1455215478519_63504_post_n7_nabble_com"
cite="mid:1455215478519-63504.post@n7.nabble.com" type="cite">
<pre wrap="">
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?</pre>
</blockquote>
<tt>Depends how important security of that communication is, and how
<br>
strong the minimum SSL settings are configured.<br>
<br>
For example if the control connection is for a large industrial <br>
plant of a type where deliberately issuing the wrong control <br>
commands can generate a major disaster (Bopal sized), then as <br>
long as people are living next to the factory or working inside <br>
the factory, it might not be secure to allow such control to be <br>
done from outside the factory, no matter how secure the <br>
connection is (the problem is that the person pushing the buttons
<br>
isn't risking his own life too).<br>
<br>
But as the potential risks get smaller, the level of security <br>
of the connection can be weighed against the dangers that would <br>
result from compromising the connection. Assessing this <br>
involves not only the technical dangers (how much damage could <br>
someone do), but also how much money and effort someone might <br>
spend to cause that damage deliberately.<br>
<br>
At one extreme, the process and its location/ownership may be <br>
such that a major superpower may dedicate some of its top <br>
secret experts to break in. At the other extreme, the <br>
circumstances may make it reasonable to assume no one will <br>
spend more than 1M$ to break into the connection (if the <br>
price of breaking in is less than that, there is a real <br>
risk that ordinary criminals might do it using stolen <br>
tools).<br>
<br>
<br>
</tt><br>
<blockquote class=" cite"
id="mid_1455215478519_63504_post_n7_nabble_com"
cite="mid:1455215478519-63504.post@n7.nabble.com" type="cite">
<pre wrap="">
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
</pre>
</blockquote>
<tt>As previously mentioned, the most common ways a certificate <br>
gets added to a revocation list are:<br>
<br>
1. The person/company to whom it was issued calls the CA and <br>
says "someone may have stolen my key, please revoke it".<br>
The standard contracts from CAs specify where to call and <br>
how quickly they have to add it to the public revocation <br>
systems.<br>
<br>
2. The person/company in whose name it was issued calls the <br>
CA and says "Whomever you issued that certificate to isn't <br>
me, revoke it at once!". Again there are are standard <br>
procedures to do this.<br>
<br>
3. A professional review/audit of issued certificates <br>
discovers something should not have been issued and <br>
contacts the CA. Many CAs have internal teams doing such <br>
reviews on a regular basis, and publicly trusted CAs are <br>
subject to independent audits at least once a year.<br>
<br>
4. A relevant event (death, bankruptcy, etc.) is announced in <br>
an official medium (such as a national government gazette), <br>
causing the CA to revoke the certificate in accordance with <br>
specific contract clauses regarding said type of event.<br>
<br>
5. A relevant event (such as a person getting fired from <br>
their job) is reliably communicated to a CA that issued <br>
a certificate no longer valid then (for instance a <br>
certificate identifying said person as being an authorized <br>
employee).<br>
<br>
All in all, these are the same situations in which credit <br>
cards or a door keys might be revoked (mechanical door keys <br>
are revoked by changing the locks).<br>
<br>
</tt>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="https://www.wisemo.com">https://www.wisemo.com</a>
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 </pre>
</body>
</html>