1 / 32

Efficient Electronic Grant Application System for NIH Grants Process

Improve efficiency in the NIH grants process by implementing a system for electronic grant applications with multiple digital signatures. Phase one successfully distributed digital certificates, and phase two aims to streamline the process by incorporating multiple vendors and certificates from participating institutions.

johnesmith
Download Presentation

Efficient Electronic Grant Application System for NIH Grants Process

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NIH-Educause PKI Pilot:Phase Two Electronic Grant Application With Multiple Digital Signatures Peter Alterman, Ph.D. Director of Operations Office of Extramural Research

  2. The Problem • NIH receives over 40,000 applications for new grants annually. Each application averages over 40 pages long; 20 copies of each are often required; each application must be duplicated and sent to over a dozen reviewers. Do the math. • While NIH has been developing strategies to convert paper to electronic processes, good solutions to the problem of electronic signature implementation have been lacking; • Institutions are busy deploying PKIs and issuing digital certificates to their faculties and staffs.

  3. Phase One Conceptual Design • Create electronic versions of grant application form; • Distribute TrustID digital certificates; • Distribute E-Lock Assured Office to affix verify two different certificates to dummy electronic applications (business process requirement); • Email signed applications to NIH.

  4. Phase One Completed Successfully • Multiple MS Word templates signed with two different digital certificates received from UW-Madison, UA-Birmingham and Dartmouth College; • ACES Certificate Arbitration Module (CAM) installed and configured at NIH; • E-Lock Assured Office, CAM-aware, installed and configured at NIH and at Institutions; • All certificates verified and validated two ways by NIH: directly to the DST OCSP Responder and indirectly through the CAM.

  5. Phase Two Goal • Receive application in electronic form signed with two different, validated, digital certificates each • digital certificates issued by Institution • several different vendors represented

  6. Participating Institutions University of Texas - Houston 

  7. What’s Different About Phase Two? • Institutions use certificates they issue; • Verify and validate digital signatures through ACES Certificate Arbitration Module (CAM); • Trust path discovery uses Federal Bridge CA cross-certified with Higher Education Bridge CA, creating an Internet-based trust infrastructure; • Use of multiple certificate providers tests interoperability within standards.

  8. Phase Two Target Outcome • P.I. logs on to Internet at his/her workstation; • P.I. links to NIH website and downloads electronic application form (PHS 398) – grants.nih.gov/grants/oer.htm; • P.I. fills out 398 at workstation; • P.I. forwards signed 398 to AOR; • AOR completes and signs it using his/her Institution-issued digital certificate; • P.I. Signs completed 398 with his/her Institution-issued digital certificate; • P.I. Mails the signed 398 to NIH as an e-mail attachment (encryption to be tested at a future date); • NIH receives signed 398, downloads it, verifies and validates signatures, and initiates internal processing.

  9. The Methodology • Build upon the results of Phase 1 • Create a controlled environment for proof of concept • Definition: Performed in a test laboratory environment to prove that the concepts and technologies to be utilized can be implemented • Transition the controlled environment of the proof of concept into a controlled pilot • Definition: Performed outside of the test laboratory to better simulate real-world situations

  10. Intermediate Requirements • (NIH cross-certifies “its” CA with the FBCA) • Stand up a Higher Education Bridge Certification Authority (HEBCA); • Cross-certify the Federal Bridge CA with the Higher Education Bridge CA; • Institutions configure directories, cross-certify their CAs with the HEBCA

  11. HEBCA E-Lock Assured Office Digital Signed Grant Appl Certificate Validation University A NIH OER Mail Server University A FBCA Internet Certificate Validation University B E-Lock Assured Office Digital Signed Grant Appl University B NIH CAM Server Certificate Validation University C Cert Status NIH OER Recipient E-Lock Assured Office Digital Signed Grant Appl E-Lock Assured Office Digital Signed Grant Appl University C E-Lock Assured Office CAM-enabled Cert Status Phase Two Concept of Operations (CONOPS)

  12. Prototype Federal Bridge Certificate Authority Firewall Cross Certified CAs RSA CA Entrust CA RSA CA i500 Directory FIP 140-1 L3 Crypto NIH Trust Domain FIP 140-1 L3 Crypto NIH Test CA • Cross certificates • CRL • Cross certificates • CRL iPlanet CA Directory • Cross certificates • ARL Verisign CA Directory System Agent NIH User Alabama Wisconsin California Texas Dartmouth Proof of Concept Architecture Higher Education Trust Domain Directory DST ARP Test CA

  13. Prototype Federal Bridge Certification Authority Entrust CA RSA CA VeriSign CA NIH Test CA DST ARP Test CA VeriSign CA iPlanet CA Client Client Client Client Client Dartmouth Alabama NIH California Texas Client Wisconsin Proof of Concept CA Interoperability Configuration Higher Education Bridge Certification Authority RSA CA Entrust CA

  14. Prototype FBCA (Peerlogic) c=US; o=U.S. Government;ou=FBCA IP address: 198.76.35.155 DSP port: 102 LDAP port: 389 TSEL: TCP/IP Chaining cn=FBCA_Directory NIH Chaining cn=nihstandin c=US; o=U.S. Government; ou=NIH IP address: 207.123.140.5 DSP port: 102 LDAP port: 389 TSEL: TCP/IP c= ; o= ; ou= IP address: DAP/DSP port: LDAP port: c=US; o=Digital Signature Trust Co; ou=ARP Testing IP address: 208.30.65.30 DAP/DSP port: 102 LDAP port:389 c= ; o= ; ou= IP address: DAP/DSP port: LDAP port: Proof of Concept Directory Interoperability Configuration HEBCA (Critical Path) c=US; o=edu; ou=HEBCA IP address: 207.123.140.5 DSP port: 102 LDAP port: 389 TSEL: TCP/IP cn=HEBCA Wisconsin, Dartmouth Chaining California, Texas Alabama cn= cn= cn=ARP Test Client CA

  15. FBCA cross cert FBCA dir cross cert HEBCA HEBCA dir get Cert,CRL via directory chaining cross cert UA ca NIH ca UA dir NIH directory trust anchor ca DAVE issued CAM E-Lock directory sender (UA) receiver (NIH) software “DAVE” (Discovery and Validation Engine)

  16. CML Libraries [Getronics] ASN1 parsing (SNACC) S/MIME parsing (SFL) Cryptographic engine LDAP and local directory retrieval (SFL) Path discovery engine (CPL) DAVE Functions Perform proper sequential calling of CML functions (i.e., the business logic) Provide call-back functions needed by CML functions Provide all CAM communications and protocol transformations Wraps CML functions into an NT service (multithreaded, failure and recovery modes, logging, etc.) DAVE Components

  17. Agency App = E-Lock Assured Office CAM-enabled CAM/CA Passing Certificate OCSP Certificate Authority/ Validation Request CAM Server • E-Lock Assured Office verifies the signature • Verifies the document has not been changed • Verifies the validity period of the certificate • Once verified, the certificate is sent to the • CAM for certificate validation to ensure that • it has not been revoked Msg Data Agency App/ CAM Discovery and Validation Engine (DAVE) • Search for issuer to validate • CRL • OSCP Responder • If chained, path reverses • If not chained, LDAP queries Verification & Validation Details

  18. CAM Log – Startup and Status Request • CAM Sees the Request from the Agency Application, e.g. E-Lock Assured Office • If the request is not an ACES request, it is sent to the Discovery and Validation Engine (DAVE) • DAVE responds by listing the nodes in the trust path • If the node in the cert path is found, a status of “0” (valid) is returned to the application

  19. Proof of Concept - CAM Log ------------------------------------ LOG STARTED: 10:12:19 << DATE: 10/26/2001 >> 10:12:19: CAM server startup 10:12:20: listener: holding to receive request #0 10:14:45: listener: holding to receive request #1 10:14:45: [0] validation request from AA: installed agency application (user should change this upon install) 10:14:46: [0] validate: serial: serial_number:01 10:14:46: [0]: validate: using default validation method 10:14:46: [0]: validate: CA found: link:localhost:123 10:14:46: [0] verification deferred to linked CAM 10:14:47: CA MESSAGE: path node: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US path node: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for FBCA,OU=FBCA,O=Mtek stand-in for U.S. Gov,C=US path node: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for HEBCA,OU=HEBCA,O=Mtek stand-in for EDU,C=US path node: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for university CA,OU=CA,O=Mtek stand-in for HEBCA university,C=US path node: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for user,OU=Users,O=Mtek stand-in for HEBCA university,C=US Validation: usage=74e058, usageCrit=0 10:14:47: [0] validate: status: 0, aces code: 0x1600) 10:14:47: [0]: periodic memory tracking : memory usage is: 154368 10:22:19: timer: running recurring save-state and ICL clean-up

  20. DAVE Server Startup Verification

  21. DAVE Server – Path Discovery and Status Return • Path discovery – this is the validation phase as CRLs are retrieved • If the CRL is retrieved, a status of “0” (valid) is returned to the CAM

  22. Proof of Concept – DAVE Log ------------------------------------ LOG STARTED: 10:11:59 << DATE: 10/26/2001 >> 10:11:59: startup... 10:12:00: Trust anchor subject DN: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US 10:12:00: listening on port 123 10:14:46: [0] saw request; aa_id=installed agency application (user should change this upon install) 10:14:46: Initial cert subject: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for user,OU=Users,O=Mtek stand-in for HEBCA university,C=US 10:14:46: dave-get-request: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for university CA,OU=CA,O=Mtek stand-in for HEBCA university,C=US [tm=7, lm=8] 10:14:46: dave-get-answer: retrieved CA cert from LDAP database 10:14:46: dave-get-request: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for HEBCA,OU=HEBCA,O=Mtek stand-in for EDU,C=US [tm=7, lm=8] 10:14:46: dave-get-answer: retrieved CA cert from LDAP database 10:14:46: dave-get-answer: retrieved CA cert from LDAP database 10:14:46: dave-get-request: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for FBCA,OU=FBCA,O=Mtek stand-in for U.S. Gov,C=US [tm=7, lm=8] 10:14:46: dave-get-answer: retrieved CA cert from LDAP database 10:14:46: dave-get-answer: retrieved CA cert from LDAP database 10:14:46: dave-get-request: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US [tm=7, lm=f]

  23. Proof of Concept – DAVE Log (cont’d) 10:14:46: dave-get-answer: retrieved CA cert from LDAP database 10:14:47: successfully build trust path 10:14:47: node: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US 10:14:47: node: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for FBCA,OU=FBCA,O=Mtek stand-in for U.S. Gov,C=US 10:14:47: node: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for HEBCA,OU=HEBCA,O=Mtek stand-in for EDU,C=US 10:14:47: node: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for university CA,OU=CA,O=Mtek stand-in for HEBCA university,C=US 10:14:47: node: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for user,OU=Users,O=Mtek stand-in for HEBCA university,C=US 10:14:47: dave-get-request: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US [tm=18, lm=f] 10:14:47: dave-get-answer: retrieved CRL from LDAP database 10:14:47: dave-get-request: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for FBCA,OU=FBCA,O=Mtek stand-in for U.S. Gov,C=US [tm=18, lm=f] 10:14:47: dave-get-answer: retrieved CRL from LDAP database 10:14:47: dave-get-request: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for FBCA,OU=FBCA,O=Mtek stand-in for U.S. Gov,C=US [tm=7, lm=f] 10:14:47: dave-get-answer: retrieved user cert from client database 10:14:47: dave-get-answer: retrieved user cert from client database

  24. Proof of Concept – DAVE Log (cont’d) 10:14:47: dave-get-request: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US [tm=7, lm=f] 10:14:47: dave-get-answer: retrieved user cert from client database 10:14:47: dave-get-request: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for NIH CA,OU=CA,O=Mtek stand-in for NIH,C=US [tm=18, lm=f] 10:14:47: dave-get-answer: retrieved {special type} from client database 10:14:47: dave-get-request: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for HEBCA,OU=HEBCA,O=Mtek stand-in for EDU,C=US [tm=18, lm=f] 10:14:47: dave-get-answer: retrieved CRL from LDAP database 10:14:47: dave-get-request: emailAddress=stillson@mitretek.org,CN=Mtek stand-in for university CA,OU=CA,O=Mtek stand-in for HEBCA university,C=US [tm=18, lm=f] 10:14:47: dave-get-answer: retrieved CRL from LDAP database 10:14:47: validation successful 10:14:47: Validation: usage=74e058, usageCrit=0 10:14:47: [0] answered with status: 0

  25. Development Status (as of Friday, 10/26/2001) • Representative Directory Structures; • Cross-certs issued: NIH-stand-in*FBCA, FBCAHEBCA, HEBCAARP Test (DST) • Also have fully working test environment with temporary stand-ins for all 4 CAs • Corresponding directory chaining and cross references • NIH-stand-in is DAVE’s trust anchor, and is only directory DAVE speaks to directly • Directory clock synchronization • Correct CA cert retrieval, directory traversal, and cross-cert retrieval; • Correct communications with CAM.

  26. End-to-end Directory Chaining In Place:DITS for all 4 Directories Appear On One PC - NIH, HEBCA, FBCA, and DST

  27. Issues and Resolutions • Directory Structures and Services • Issue: No underscores in DNs (CML altered) • Issue: Some directories change binary data upon import and upon return via chaining agreements!!! • Resolution: Some certs changed to indefinite length ASN1 encoding. Temporarily solved via another version of the I.500 directory. • Resolution: PKCS7 cross-cert pairs stripped of certain ASN1 sets. Temporarily solved via same directory and by loading each individual cross-cert pair element incACertificateattribute (not combined in thecrossCertificatePairattributes)

  28. DST Business Model Common elements in PKI domains negate need to traverse bridges CML goes up issuing chain, finds cross-cert with FBCA, correctly recognizes UAB end-entity cert and NIH trust anchor in same PKI domain, bypasses HEBCA bridge This is correct PKI functionality, not a problem Observation cross-certifies with FBCA (as NIH trust anchor) Self-Signed Root Non-issuing CA cross-certifies with HEBCA Issuing CA Issuing CA UAB end-entity certs NIH end-entity certs

  29. Current Development Focus • To move from Proof of Concept to Pilot: • Path traversal and discovery always works! However, the CPL occasionally does not recognize that it has discovered the complete path (works with test CAs and test certs). • Some CRLs are not parsed correctly by the CML • The CML may or may not be able to parse a true cross-cert pair (not yet attempted) • Expansion of the interface from the CAM to the Agency Application to utilize OCSP extensions

  30. Next Steps • Complete Development and Test of DAVE and CAM and have all working bits talking to each other in recognizable language; • Replace Stand-in CAs and Directories with Institutions’ CAs and Directories; • Verify and Validate Institution-issued digital signatures on electronic grant applications; • Go out and celebrate!

  31. Want More? • Peter Alterman: peter.alterman@nih.gov • Deb Blanchard: dblanchard@trustdst.com • Monette Respress: mrespres@mitretek.org

More Related