Martin Bartosch wrote:
if you asume, there would/could be an 'process' doing such things, what should prevent another malicous process to provide you with wrong data?5. Audit logging - Audit of RA and CA operations to a tamper proof signed log. This is possibly a requirement to achive any form of accreditiation.
this brings us to another requirement that is not easy to implement but would really be important:
OpenCA should know exactly how many private key operations are performed on the CA key. If using a HSM that is kept online (with usable private key opened), then another process might abuse the HSM to perform private key operations.
We cannot do much to *prevent* this, but it can be *detected*: Some HSMs support a read-only "private key usage counter" that is incremented every time the private key is accessed. By reading this counter, OpenCA (or an Auditing System) could detect if unauthorized key operations have happened circumventing control of OpenCA.
since the system ist then already compromised
a solution could be to use so called hashing-logfiles including a media-break to achive trustworthy data... (on a separate loggin facility of course)
works like this: every log entry gets hashed and the last hash included and the time so you get a always an actual hash, an atac could insert in any further state an own value or change one and then recalc all following hashs, to prevent this, you print for example every hash on paper on a printer - so changes in hash can be detected very easily and an atac needs physical access to the printer to be undetectable...
so this would make the log safe and auditable and trustworthy as far as the collected data is realiable...
but than you had to read those hsm counters in a not compromised system state... otherwise some could manipulated the software provididing you whith the number ;o)One module that supports this is nCipher's nShield HSM. Unfortunately this function is not available with the stock CLI tools provided with the HSM. Instead, custom programming is required against the nCipher API, and for this the nCipher SDK is required.
so mainly it gonna get kind of difficult to selfprotect the system whith its own - if you assume there could be malicious tasks running... they can do this to...
6. Script/environment validation - A function that ensures OpenCA is running in a "known" environment. Perhaps md5 signature creation (after installation) and run time validation.
now, if you can't trust your base, you cant trust your counters and anything else - isn't it?Yes, but this could also be done using a host based IDS. Not too important, I think.
thats why i had an idea of building something like an high risk environment, which is based on a cd-rom or some similar write protected media, changeable configuration data and exchange data are hold on writeable media (like usb-based-hardware, maybe encryptable), and the os
supports something like se-linux or similar
this should get to quite a secure(able) comuting base, which is trustable... if we assume we have all components online and therefore can be attaced
but this is for sure - outside the scope of openca itself, its just the environmental view where it should running finaly
(here is an picture for illustration which i created but not more :o( http://lab.x-dense.org/openca/hr-concept-1.gif
this is more general view for usage with an laptop for example, so in an installed system Crypto Device I would be an real HSM and 'Volatile Memmory III' would be not necesarry when one uses online systems, as there would be no ca-operator of course, but most probably an ra-operator at the ra... and so on
but its just to make the idea more clear... and i think, finaly we wont get around such a kind of trusted and secured computing base for point
12. ;o)
but for sure, thats not so importend at the current state, just wanted to mention it...
9. Web based OpenCA configuration and management - Enhancing the existing management screens to allow management of certificate roles and extensions, access control settings and node management i.e. a front end to the OpenSSL config files.
Sounds like a *lot* of work. I am fine with today's XML based configuration. I don't like the template -> config file hack much, though.
yeah, a (webbased) frontend for the config would be fine
13. Automated CA Key rollover When reaching the end of the CA certificate lifetime, there is a certain point after which no usable end entity certificates can be issued whose desired validity *fully* fits into the CA certificates validity.
yes, thats a common problem
i don't understand why? it would be enough to isse a new certificate before the 'crl-only' time of the actual one starts... i see no sense in doing it half the time of the actual one is over, it doesn't changes anything in the workflow so far - or did i miss something?To address this problem, we issue a rollover certificate that becomes valid when reaching half of the CA certificates validity range: notBefore(new) := notBefore(old) + ((notAfter(old) - notBefore(old) / 2)
New certificates are *always* and *only* issued using the "newest"
CA certificate available. After rollover happens (automatically by
reaching the "NotBefore" date of the new certificate) the old
one still remains valid and is *exclusively* used for CRL
generation, revocation etc.
thats common to do so
This ensures that you will always be able to issue certificates
with a lifetime up to half of the "standard" CA certificate
lifetime.
that may be a reason to do so (and now it gets clear), but usaly one have a policy and therefore one knows, what would be the longest validity of issued certs... and this would automagicaly become the timeout value for the actual running ca/pki..., so usaly it doesn't happend that i suddenly wann issue a certificate wiht a longer lifetime than stated in my policy for the running ca or it would be just written in it...
CA operators need only remember to issue a new rollover certificate within the first half of the currently used certificate's validity. BUT the CA software has to be able to deal with this.
at the moment it is 'solved' in setting up an entirely new pki since a new ca-certficate means to have a new tree in the end since you generate new keys to usaly
so this would need some more redesigning of the interfaces, so one can handle more than one ca (in the end of day) with it, because an rollover means to set up a new one... even if it doesn't sound like, i think
it would also mean to reasign the already requested feature of allowing a set of trusted operators signed by a differen ca (in this case, the old one, since those certs had been issued by the old ca (keys)) and the knew one can't directly proofe them
thats also not unimportend for backing up and documentation of an pki-(ca)-lifecycle... since you may have to save the keys for some time, for other reasons... (also issued ones)
so i think this automated rollover thing may be a bit more complex then just issuing a new ca-cert (and generating new key-pairs)
since its complex task, that may be a reason for all those well know issuer (verisign and co) to choose such long validity times for there core and root certs... to just 'work around' by time this issue...
those are always good points ;o) and yeah sometime i'm also quite lost in the code...14. Improved debugging support I frequently get lost in the system when trying to debug things, often I wonder what functions get executed by OpenCA, the CGI system seems very opaque to me (and I consider myself an experienced Perl hacker)
15. Improved error handling I have seen OpenCA report crude error messages on seemingly harmless error conditions. When checking the code it was often something like an uninitialized variable that was used to call a method on.
greetings dalini
--
Ives Steglich Email: [EMAIL PROTECTED]
System Administration Tel.: +49 (0)3677 - 69 4882
Fax: +49 (0)3677 - 69 4399Fraunhofer Institute for Digital Media Technology Langewiesener Strasse 22 98693 Ilmenau Email (private): [EMAIL PROTECTED] Germany http://www.openca.org
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-devel
