Frequently Asked Questions and Working Logic

<h1 style={{fontSize: '30px', fontWeight: 'bold', margin:'40px 0'}} align="center">Frequently Asked Questions</h1>

<h1 style={{fontSize: '20px', fontWeight: 'bold'}}>Question 1: Are there any companies that have switched to the current signature infrastructure? Were there any problems with the transitions?</h1> <p style={{fontSize: '16px'}}>We have customers who use our current E-Signature infrastructure. There is no problem with their use at the moment.</p>

<h1 style={{fontSize: '20px', fontWeight: 'bold'}}>Question 2: Are there any details we need to take precautions or know in order to avoid problems with the current signature infrastructure?</h1>

In order for our new E-Signature infrastructure to work, Java and .NET Core 3.1 must be installed on the server and user computers.

During the signature process of the servers used, access problems are experienced due to internet output restrictions. The server must be able to access the Internet. The problem here is that at the completion of the signature process, the KamuSM API goes to different addresses and performs operations such as certificate revocation list check, certificate verification, signature check. These addresses should be given full access to and from the server. It should be attached as a whitecard.

He does not know the list of these addresses in KamuSM and cannot give us the full list because it varies. During the checks from the customers, we have a list as follows. New addresses can also be added. The current list is as follows; <table > <tr> <th>ip</th> <th>address</th> </tr> <tr> <td>193.140.71.25</td> <td>``````<a href="https://zd.kamusm.gov.tr" style={{color: 'blue'}}>zd.kamusm.gov.tr</a>``````</td> </tr> <tr> <td>193.140.71.24</td> <td>``````<a href="https://ocsp.kamusm.gov.tr" style={{color: 'blue'}}>ocsp.kamusm.gov.tr</a>``````</td> </tr> <tr> <td>193.140.71.24</td> <td>``````<a href="https://ocsp3.kamusm.gov.tr" style={{color: 'blue'}}>ocsp3.kamusm.gov.tr</a>``````</td> </tr> <tr> <td>193.140.71.23</td> <td>``````<a href="https://ocsp4.kamusm.gov.tr" style={{color: 'blue'}}>ocsp4.kamusm.gov.tr</a>``````</td> </tr> <tr> <td>193.140.71.52</td> <td>``````<a href="https://ocsp5.kamusm.gov.tr" style={{color: 'blue'}}>ocsp5.kamusm.gov.tr</a>``````</td> </tr> <tr> <td>212.174.244.151</td> <td>``````<a href="https://ocsp.turktrust.com.tr" style={{color: 'blue'}}>ocsp.turktrust.com.tr</a>``````</td> </tr> <tr> <td>212.174.244.99</td> <td>``````<a href="https://crl.turktrust.com.tr" style={{color: 'blue'}}>crl.turktrust.com.tr</a>``````</td> </tr> <tr> <td>212.174.244.152</td> <td>``````<a href="https://ts.turktrust.com.tr" style={{color: 'blue'}}>ts.turktrust.com.tr</a>``````</td> </tr> </table> <p style={{fontSize: '17px', textDecoration: 'underline'}}>Helper extensions about Digital Signature: </p>

<br/> http://www.turktrust.com.tr/sil/TURKTRUST_Nitelikli_SIL_h4.crl http://kamusm.bilgem.tubitak.gov.tr/

<p style={{fontSize: '17px', textDecoration: 'underline'}}>Apart from these, the following links should also be allowed depending on the signature card used. </p>

E-SignatureTR: http://ocsp.E-İmzatr.com <br/> E-Tugra : http://ocsp.e-tugra.com/status/ocsp <br/> e-Güven: http://ocsp2.e-guven.com/ocsp.xuda &http://sil.e-guven.com/ElektronikBilgiGuvenligiASGKNESIS6/LatestCRL.crl

<p style={{fontSize: '17px', textDecoration: 'underline'}}>WhiteCard should be issued Addresses :</p> <p>.kamusm.gov.tr <br/>.turktrust.com.tr <br/> .E-İmzatr.com <br/>.e-guven.com <br/> *.e-tugra.com <br/>``````</p>

<h1 style={{fontSize: '20px', fontWeight: 'bold'}}>Question 3: Will it work stably and smoothly if we switch to the current signature infrastructure?</h1>

The current signature infrastructure is working stably. During the development phase, support was received from <b>TÜBİTAK KamuSM</b>, which did the actual work, and development was carried out together. Companies that provide signing infrastructure have developed their products using KamuSM infrastructure. Since we used the same infrastructure while developing our product and developed the algorithm together with KamuSM during the support phase, we developed similar structures in terms of security, privacy and usage with other signature applications. <b> The only difference is that this product is Bimser's own product and can be applied to all Bimser products.</b>

Periodically, in certificate subjects, there may be addresses that need to be accessed in KamuSM requests during the signature process. In such cases, renewal or correction of the certificate store may be necessary for certificate subjects. If there are access problems, it may be necessary to carry out the necessary work over the network. Apart from such issues, our signing infrastructure works stably and smoothly.

So as a result, since the same infrastructure is used, the signature results and verification processes are the same as KamuSM and the signer application. After all the signing adjustments to be made in the processes to be used, the signature process can be carried out smoothly.

<h1 style={{fontSize: '20px', fontWeight: 'bold'}}>Question 4: Can you ensure the security of our signature certificates and information?</h1>

Like other companies that provide signing infrastructure, we have developed our product with the necessary infrastructure and algorithms through <b>TÜBİTAK KamuSM</b>. We offer the same assurances about security, privacy, and certificate integrity as any other signing infrastructure provider.

<h1 style={{fontSize: '20px', fontWeight: 'bold'}}>Question 5: Is the signature software -DSClient- still being developed and updated?</h1>

Now, for close to 1 year, more than 20 customers have moved to this structure and used it live, so the radical changes have been completed and we have a stable version 1.4.5. This version is used everywhere.

In an extreme case, an msi is created by taking the current version and the update process can be completed in a short time by running it directly. The DSClient application may receive updates due to different needs and detected issues.

<h1 style={{fontSize: '30px', fontWeight: 'bold', margin:'40px 0'}} align="center">Bimser Digital Signature Working Logic</h1>

The digital signature application was developed by using the KamuSM Ma3api infrastructure offered by Tübitak and signature companies. In this context, KamuSM throws requests to the open ends of the API and receives the results and EBA. It is a web-api application that forwards to ASP.NET.

Here, in order to protect the customer signature data and ensure certificate confidentiality, we developed the algorithm as follows; First, the customer plugs the signature dongle into their local computer. Opens the EBA.NET from the browser to request signing on EBA. EBA.NET client server is also installed. We install the signature application on both the customer server and the local machine. In the first stage, when the sign button is triggered, the initialize process is triggered on the customer server to obtain a hash information of the data to be signed and this information is transmitted to the customer computer. We perform the sign process, which is the 2nd stage, on the customer computer where the signature dongle is installed, that is, on the local machine. This way, we don't move customer certificate information outside of the local machine, and we don't allow traffic to be spoofed and retrieved. Then, after the signature process takes place locally, we take the signed hash information of the document and return to the server again in the 3rd stage finalization stage and change the signed data. The reason why the hash information of the document comes back is to send the entire document and prevent performance loss.

During the development phase of this algorithm, support was received from Tubitak KamuSM and it was implemented considering its guidance for security. It was communicated by KamuSM that the companies that developed the signature used the same algorithm.

Here, if the customer has his own root certificates, he can add the following section at the address where he is installed to add them. Apart from that, it automatically pulls other public certificates from the addresses in 'certificatestore.svt' and updates them periodically.

<p align="center"> <img src="https://docsbimser.blob.core.windows.net/imagecontainer/ds_sss_1-06eeaf4a-0984-463e-bbb3-9d4fed7cebe2.png" alt="Bimser Solution" style={{border: '3px solid #dee0df', borderRadius:'15px', boxShadow:'3px 5px #dee0df'}}/> <img src="https://docsbimser.blob.core.windows.net/imagecontainer/ds_sss_2-71c5a0b3-c871-4240-9f79-7ff7456f5402.png" alt="Bimser Solution" style={{border: '3px solid #dee0df', borderRadius:'15px', boxShadow:'3px 5px #dee0df'}}/> </p>

In the mobile signature process, there is no need for a dongle that holds the signature information as in the digital signature. When we open the document from the browser, after the mobile signature process, kamusm; Turkcell obtains the certificate information of its mobile line from Vodafone or Avea mobile signature servers. During the initialize phase, a signing request is made to Bimser's mobile-gateway server with the certificate. Then you receive a request to the phone for verification. A verification code called Fingerprint will come up. Once validated, the 'FinalizeSigning' method sends the signed document to the application.

<p style={{fontWeight:'bold'}}>We must have the same electronic signature application installed in the mobile signature.</p>

The instant logs of the signature application are written to the installation directory of the server and customer locality where it is installed. EBA.NET also keeps error logs within itself.

In order for the application to work, apart from EBA.NET, .NET Core 3.1, Java 8 and the signature application (DS-Client) must be installed. When installing through the DS-Client installation file, the signature application is installed and runs as a Windows service. When the application is requested to be uninstalled, the installation folders and the Windows service are automatically deleted.