HARDWARE-INDEPENDENT, ADD-ON-ADDITIONAL, AND HYBRID ARCHITECTURE CENTRALIZED ELECTRONIC SIGNATURE SYSTEM AND METHOD

Abstract

This invention relates to a centralized signing system and method that provides qualified electronic signature capabilities to third-party systems with different software architectures without requiring any client-side browser plugin or local library installation. The system includes a platform-independent interface component, an iFrame-based sandbox environment that prevents signature data from leaking into browser memory, a stateless centralized signing engine supporting PAdES / CAdES / XAdES and LTV, a hybrid data flow layer where only the document summary is shared with the cloud coordination service without sending the data to be signed outside the corporate network, an intelligent certificate filtering algorithm that automatically detects regulatory-compliant certificates, a multi-layered biometric authentication algorithm that combines voice, video, and text analysis, and a load balancing mechanism that processes signing requests asynchronously.With its multi-tenant architecture and white-label support, it enables multiple organizations to share the same infrastructure while maintaining data isolation, and makes compliance with the Electronic Signature Law No. 5070 and ETSI standards mandatory at the technical configuration level.

Description

HARDWARE-INDEPENDENT, ADD-ON-EXTENSION AND HYBRID ARCHITECTURAL CENTER ELECTRONIC SIGNATURE SYSTEM AND METHOD Technical Area The invention is compatible with different software architectures and operating systems. client systems that have any browser plugin, local library setup or hardware dependency without requiring, through a centralized signing engine Qualified according to PAdES, CAdES and XAdES standards. Electronic signature with timestamp and long-term verification. (LTV) capability; enabling the transfer of internal data to the external network. It allows signing via cloud coordination without being removed. iFrame-based isolated with a hybrid security architecture that recognizes It combines a messaging layer and a signature layer. the process is based on biometrics using voice, video and text analysis. Electronic signature systems, which are enhanced with verification, in the fields of cryptography, cloud computing and cybersecurity It encompasses an invention relating to a system and method. State of the Art Electronic signature technologies, digital document verification, and It is becoming increasingly important in identity verification processes. However, the technical architectures of existing solutions It has various structural constraints and these restrictions affect both corporate integration processes and final This negatively impacts user experience. In the known technology, electronic signature processes To achieve this, a Java Applet is needed on the user side. 1 ActiveX component, browser extension or the establishment of local libraries similar to AKIS is mandatory This approach is maintained; different operating systems and This leads to incompatibility issues between browser versions. opening, separate installation and update on each client system. This requires a process that increases the burden of corporate IT management. and especially on mobile platforms, it becomes unusable. This is the case. Indeed, "Data" numbered US2008163337A1 In the document titled "Certification Methods and Apparatus", electronic signature processes are private on the user terminal. a can be run without requiring any hardware or software an approach has been put forward; however, the solution described in this document, multilayer hybrid via a central signing engine architecture, on-premise data management, or iFrame-based isolated architecture. It does not include a messaging layer. In the document in question... The defined "zero-footprint" concept is only client-side. aimed at reducing dependency at the institutional level hybrid data flow orchestration and hardware-independent multi-functionality Technical requirements for multi-tenant buildings It does not offer the necessary mechanisms. In the context of cloud-based signing solutions, in particular... highly regulated sectors such as banking and the public sector data in areas containing requirements within the organization network Removing it poses serious legal and security risks. This gives rise to the Electronic Signature Law No. 5070 in Türkiye. and within the framework of BDDK regulations, the document to be signed transmitting its content to third-party cloud infrastructure This could constitute a violation of regulations; therefore, cloud computing alone is not sufficient. based solutions are viable for enterprise use. It cannot offer an option. The voice in document number WO2019022629A1 The biometric-based signing method has been explained. Together, the system described in this document; corporate data 2 hybrid on-premise / cloud that meets security requirements coordination architecture, stateless data flow, and multi Layered (voice + video + text) biometric authentication It does not offer the combination together. iFrame and browser-based isolated messaging technologies In terms of the known technique, postMessage in an iFrame environment structured control flow via protocol There are studies indicating that this has been achieved. However, this The approaches described in the studies involve scanning signature data. Special security measures to prevent leakage from memory. The mechanisms are isolated in the signature session's sandbox environment. and secure data with a centralized signing engine. inadequate in ensuring simultaneous transfer. It remains. Indeed, the scanner is also in the US2008163337A1 family. Data isolation and session-based signing process How security is ensured is a technical solution. They could not be reunited. Long-term validation (LTV) and PAdES Within the framework of these standards, the existing solutions are largely... It relies on ready-made libraries (iTextSharp, DSS, etc.); Library signature dictionary management and OCSP / CRL integration. It includes certain configuration restrictions in this regard. In the current technology, LTV data is signed using a centralized signing engine. processing within the institution and PDF signature dictionary a unique way of managing it in accordance with its policies The technical mechanism has not been described. This technique is also known in smart certificate filtering. containing multiple electronic signature certificates Automatic detection of valid certificates in environments It does not offer an adequate solution for this. 3 Compliance with legislation (Law No. 5070, ETSI TS 102 280) qualified certificates are automatically distinguished from other certificates. an option that minimizes user intervention No technical explanation regarding the algorithm is known. It is not currently available in technology. When all these shortcomings are considered together, the current situation is as follows: In terms of technology, there are no plugins or libraries on the client side. no installation required, no outreach to the external network a central engine that handles the signing process, iFrame / sandbox-based secure messaging layer, intelligent certificate filtering, LTV-supported proprietary signing engine. and multi-layered biometric authentication in a single integrated system. no technical solution offered within the architecture This is evident. This invention is based on the techniques described above. to resolve problems and shortcomings of known techniques It was developed for this purpose. Problems that the invention aims to solve. This invention, in the priori state of the art, is described above. in order to address shortcomings and structural limitations It has been improved and solves the following technical problems: It aims to... 1. Client-Side Software Dependency Problem In known electronic signature solutions, the signing process To achieve this, a Java Applet is needed on the user side. ActiveX component, browser plugin or native AKIS-like application The establishment of libraries is mandatory. This necessity; different operating system and browser versions 4 This leads to incompatibility issues between each user. separate installation and periodic update process on your device This requires reducing the management burden on corporate IT departments. significantly increasing and especially on mobile platforms also makes its use impossible on limited corporate devices. It brings about. The primary purpose of this invention is; any plugin, local library or client-side software no installation required, just a standard web browser. via browser and independently of the operating system a place where electronic signature transactions can be carried out The goal is to present systems and methods. 2. Platform and Browser Independence Problem Most known solutions are for specific operating systems. (Windows, macOS) or browser types (Internet Explorer, Chrome) is limited. This situation; corporate restricting users' hardware and software preferences, In institutions with different platforms, parallel and separate... independent infrastructure investments are required, the system negatively impacts its scalability and sustainability. It has an impact. The second purpose of this invention is; desktop, laptop, all platforms including tablets and mobile devices in browsers, as well as different programming languages ​​and third-party frameworks (Java, .NET, Python, etc.) with a single type of integration interface across the systems a workable, platform and browser independent architecture to reveal. 3. Corporate Integration Complexity and Long Implementation Period Process Problem In the current technology, the electronic signature infrastructure is provided by third parties. integration with corporate systems; complex APIs configurations, dependency management, certifications due to infrastructure setup and testing processes, weeks This allows organizations to continue their digital transformation. negatively impacting the time and cost budgets of their projects It has an impact. The third objective of this invention is central signing. its engine for enterprise systems with different architectures through a standard integration layer (wrapper / API) "Plug and play" in as little as two business days. It can be commissioned with the model, installation and configuration The goal is to offer a system design that minimizes complexity. 4. Corporate Data Security and Regulatory Compliance Problems In Salt cloud-based signing solutions, the document to be signed content outside the corporate network, to third-party cloud servers This needs to be communicated. This situation is governed by Law No. 5070 in Türkiye. Electronic Signature Law, BDDK regulations and KVKK (Personal Data Protection Law) This creates serious legal risks and sensitive financial implications. or the leakage of personal data outside the organization is a data breach. It can have the characteristics of being subject to high regulatory sanctions. This could be the subject. The fourth purpose of this invention is; to be signed documents and personal data remain within the organization's network cloud infrastructure provides coordination of the signing process. by conducting it through this channel, thereby ensuring both data security and it also offers ease of use, along with additional features like a VPN. a hybrid security system that does not require an infrastructure component and The goal is to develop a communication architecture. 6 5. Signature Data Leakage Problem in Browser Memory In browser-based signing solutions, signature data and Writing cryptographic keys to the browser's memory, made accessible by other tabs or extensions its arrival and leaving residual data in memory after the session This invention poses serious cybersecurity risks. The fifth objective is to generally store signature data in the browser's memory. an iFrame-based sandbox that prevents writing in an accessible format isolated from its environment via the postMessage protocol, type-secure and encrypted messaging and data transfer by creating a layer, the client-side attack surface The goal is to minimize the attack surface. 6. Zero-Footprint Client Architecture Problem In the known technique, the signing process must be completed or Temporary files on the user's device during the verification process Session remnants or cache data are being generated; this This situation contradicts corporate security policies and especially in shared computers (kiosks, counters, (branch terminals, etc.) create serious security vulnerabilities. The sixth purpose of this invention is; after the signing process is completed then any temporary files on the user's device, This leaves no cache data or library remnants. thus technically minimizing the attack surface The goal is to implement a "zero-footprint" client architecture. 7. The Problem of Lack of Multilayer Biometric Authentication Authentication in known electronic signature solutions is a major issue. to a certain extent PIN entry, smart card or OTP (one-time) with one-factor or two-factor methods (such as password) 7 These methods are limited. These methods involve obtaining identity information. theft, SIM card cloning or PIN sharing, etc. It is proving inadequate in the face of social engineering attacks. proof of the signatory's actual "physical presence" unable to do so and potential legal disputes that may arise in the future a biometric evidence record that has sufficient probative value It is unable to create it. The seventh objective of this invention is; at the moment of signature The person's voice is streamed in real-time using a recorded voice library. comparing, processing the video footage, and the consent text Three-step biometric verification that analyzes spoken audio. through its algorithm, it unifies the "person-device-process" triad. cybersecurity and binding within a cryptographic envelope a multi-layered system with high value in terms of legal proof The goal is to develop a biometric authentication mechanism. 8. The Smart Certificate Selection Problem Having multiple electronic signature certificates loaded in various environments (smart card, USB token, software certificate), which certificate during the signing process Determining where it will be used largely depends on the user. This situation is due to invalid, expired, or expired documents. This can lead to the selection of certificates with an insufficient level of qualification. the creation of signatures that have no legal validity this causes and disrupts corporate compliance processes. It causes harm. The eighth purpose of this invention is; Law No. 5070 and qualified within the scope of ETSI TS 102 280 standards. automatically detects electronic signature certificates, validity period, quality level and intended use by evaluating the criteria in real time, the most suitable the certificate selected and user intervention minimized The goal is to offer an intelligent certificate filtering algorithm. 8 9. Long-Term Validation (LTV) and PAdES Management Problem In the known technology, signatures in PAdES format are long-term. Addition of validation (LTV) data; largely ready third-party libraries (iTextSharp, DSS, etc.) it relies on and the configuration constraints of these libraries due to corporate policies regarding the PDF signature dictionary Privatization is not possible within this framework. This situation; it weakens the long-term verifiability of the signature. both institutions' own business rules and signature infrastructure It prevents reflection. The ninth objective of this invention is; LTV data (OCSP responses, CRL lists, time) (stamps) processed within its own signing engine, PDF signature glossary in accordance with corporate policies and ETSI standards managing in line with and relying on readily available libraries a unique signature and verification architecture that eliminates to place. 10. Asynchronous Load Distribution and High-Volume Processing Capacity The problem High-volume document signing and verification at the corporate level. synchronized processes using known centralized signing solutions It creates a bottleneck due to its processing architecture; Simultaneous multiple signature requests system It reduces performance and increases response times. The tenth objective of this invention is; on the central signature engine executed asynchronously and dynamically utilizing system resources through a load distribution algorithm that optimizes multiple documents simultaneously per second allowing for signing and verification, The goal is to design a scalable processing architecture. 9 General Purpose All of the technical problems listed above together When evaluated, the overall purpose of this invention is to provide the client with... requiring no plugin or software installation on your end, iFrame / sandbox that stores corporate data within the corporate network Multilayered biometrics with an isolated messaging layer based on verification, smart certificate selection, LTV-supported original signing motor and asynchronous load distribution mechanism in one bringing together within an integrated system architecture; hardware independent, platform independent and regulatory compliant a central electronic signature system and method emerged. to place. Disclosure of the Invention DETAILED DESCRIPTION OF THE INVENTION The invention relates to system architecture, components, data flows, and methods. It is explained in detail, step by step. The explanation is limited to the preferred application methods. not, but merely without narrowing the scope of protection of the invention This is illustrated through example application scenarios. 1. GENERAL SYSTEM ARCHITECTURE The system described in the invention consists of a client layer and a central unit. Central Signing Engine Layer and Service Orchestration Layer It consists of three basic layers. The client layer processes the user's electronic signature. initiated, accessed via a standard web browser and any plugins, local libraries, or client-side interface component that does not require software installation It includes third-party applications at the client level. a signing interface that provides complete isolation between An iFrame-based sandbox environment (102) is running. The subject is a sandbox environment; signature data, cryptographic session main information and user authentication data to prevent leakage into application memory It is structured. Central signing engine layer; PAdES, CAdES and XAdES Signing in formats, adding timestamps, OCSP verification, CRL query and long-term validation (LTV) data ready-made third-party processing capabilities a unique signing system that works independently of libraries It includes the motor (104). This motor is stateless. designed with an architecture that simultaneously accommodates multiple elements the signature requests from the institution are independent of each other a multi-tenant structure that can function in this way has. Service orchestration layer; on-premise signature servers, cloud coordination services, certificate management module, biometric authentication service and load balancing mechanism together with the orchestration component (106) This layer prioritizes signature requests. queued asynchronously according to order and system capacity. It receives and distributes. 2. Plugin-Free and Platform-Independent Integration Layer The system in question can be used with different programming languages ​​(Java, .NET, Third-party software developed with Python, PHP, etc., and frameworks. enterprise systems, a standard RESTful API or Web An abstraction that connects via the service interface and It contains a wrapper layer (108). 11 The wrapping layer in question performs the following functions: It brings: - The third-party system's signing request is a standard converting to data format (JSON / XML), - The document or data to be signed is outside the institution's network. to be transmitted to the central signing engine without being extracted establishing the necessary encrypted communication tunnel, - The signing result is configured in the third-party system. transmitted as a response object, - Institution-based authentication, authorization, and auditing. Centralized management of audit log processes. This structure allows institutions with different architectures to... systems, any in their application code It must contain a cryptography or signature library. It gains electronic signature capability without any delay. Integration process; standard API documentation, ready-made SDK. two jobs through components and configuration templates It is designed to be completed within the day. 3. IFRAME-BASED SANDBOX ENVIRONMENT AND SECURE MESSAGING PROTOCOL The iFrame-based sandbox environment within the scope of the invention (102), There is no connection between third-party applications and the signing interface. It creates an insulated working environment that provides insulation. Communication between the sandbox environment and the external application, a secure messaging protocol with the following features (110) is carried out through: Communication is only via the postMessage API. This is being implemented and involves direct DOM access. It is being blocked. 12 Each message undergoes origin validation and message type verification. through the control and type-safe verification filter is being carried out. Signature data, cryptographic key material, and biometrics. data is released unencrypted outside the sandbox boundaries. It is not being transmitted. Temporary data within the sandbox environment when the session ends. objects are cleaned safely and the user No residual data is left on the device. The messaging protocol is vulnerable to repeat attacks. a unique nonce for each session for protection purposes It uses its value. This structure is encountered in browser-based signing processes. memory leak, session copying, and cross-tab data. cybersecurity threats such as leaks at a technical level It eliminates. 4. HYBRID SECURITY AND DATA FLOW ARCHITECTURE The system that is the subject of the invention is related to corporate data security and usage. To simultaneously meet the convenience, the following hybrid It implements the data flow model (112): Step 1 – Request Initiation: The user, at the client level It initiates the signing process via the interface. To be signed document or data object, on-premise signature within the corporate network stored locally on the server (114); outside the corporate network It is not being transmitted. Step 2 – Coordination Tunnel Setup: Service Orchestration layer, on-premise server on the corporate network and cloud 13 encrypted, session-based coordination service It establishes a (session-based) communication tunnel. This tunnel only metadata related to the signing process (document digest / hash, signature) (parameters, certificate information) carries the document content. It does not transmit to the cloud. Step 3 – Signing Process: The central signing engine, on-premise By receiving the document hash from the server, the user signing process with electronic signature certificate It performs OCSP verification and timing during signing. The stamping process is carried out simultaneously. Step 4 – Processing LTV Data: Centralized signing engine; OCSP responses, CRL lists, and timestamps. tokens in ETSI PDF signature dictionary It is installed in accordance with the PAdES-LTV standard. Step 5 – Result Communication and Registration: Signed document on-premise The audit log is transmitted to the server centrally. temporary session data is created and securely stored It is cleaned. This model includes additional infrastructure such as VPN, DMZ, or private network connections. three-layered, BDDK compliant system without requiring additional components. (three-tier) security architecture at the software level It meets the needs. 5. SMART CERTIFICATE FILTERING ALGORITHM Containing multiple electronic signature certificates In these environments, the system that is the subject of the invention consists of the following steps: It runs the smart certificate selection algorithm (116): 14 Step 1 – Certificate Inventory Creation: The system collects certificates from connected smart devices. by scanning the card, USB token or software certificate store It lists all available certificates. Step 2 – Qualification Level Verification: Each certificate is subject to Law No. 5070. Qualified electronics within the scope of the law and ETSI TS 102 280. whether it has the status of a signature certificate, and whether it is reliable. issued by the certificate service provider not regulated and the purpose of key usage It is evaluated in terms of its suitability for the signing process. Step 3 – Validity Check: Validity period, cancellation status. (OCSP / CRL) and usage restrictions in real time. It is questioned. Step 4 – Prioritization: Quality level, validity according to the criteria of duration and intended use A weighted scoring model is applied and the most The certificate with the highest score is automatically selected. Step 5 – User Consent (Optional): Corporate Policy When required, the automatically selected certificate is approved by the user. The process is presented via the screen; otherwise, the user It continues without the need for intervention. 6. MULTI-LAYER VIDEO SIGNING AND BIOMETRIC AUTHENTICATION ALGORITHM The biometric authentication mechanism covered by the invention is voice-based. analysis, video image processing, and text verification. multilayered biometrics that use its components together It includes the approval algorithm (118). This algorithm It includes the following steps: Step 1 – Consent Text Generation: The system generates a consent text specific to the transaction to be signed, an unchangeable consent text (e.g., contract summary, It generates and presents the transaction amount and date to the user. Step 2 – Starting Video and Audio Recording: The user's device real-time video via its camera and microphone and Audio recording begins. Recording duration and quality parameters are set. It is automatically configured by the system. Step 3 – Read-aloud and Speech Recognition: User approval read aloud text, speech recognition engine (120) it is converted into text via and by the system It is compared with the generated approval text. The match rate (match) When the score falls below the determined threshold, the transaction is processed. It terminates automatically. Step 4 – Voice Biometric Verification: The recorded voice pattern, pre-generated voice biometrics belonging to the user It is compared with the profile (voiceprint). This step is another detecting the person's attempt to sign in on behalf of the username It functions as an authentication layer. Step 5 – Biometric Data Sealing: Voice analysis score, video Record summary and confirmation text match rate; signing process included inside the cryptographic envelope It is signed. In this way, the "person-device-transaction" triad is completed. Only one verifiable record is kept. Step 6 – Verification Recording and Archiving: Biometric Verification all data related to the process (audio recording summary, video metadata, (matching rates, timestamp, device fingerprint) an unalterable audit log This record is stored within the central signing engine. 16 proof for future legal disputes It constitutes independent evidence that carries value. Step 7 – Integration with the Signing Process: Biometrics Once the verification is successfully completed, the system will sign. transmits a confirmation signal to the motor (104) and electronic signature The process is initiated when biometric verification fails. If so, the signing process is blocked, the event is recorded, and The user receives a notification after two failed attempts. The session will be automatically terminated for security reasons. 7. PADES / LTV SIGNATURE DICTIONARY MANAGEMENT METHOD The original signature engine of the system subject to the invention (104), PAdES long term electronic signatures in this format To ensure verifiability, the following LTV data processing and signature dictionary management method (122) It is implementing: Step 1 – Signature Generation: Central signing engine, by accessing the user's certificate and private key It generates the cryptographic signature on the document hash. Signature value; selected algorithm (RSA, ECDSA), key based on length and hash function (SHA-256, SHA-512) It is structured. Step 2 – Obtaining a Timestamp: The signature value is obtained from an authorized source. To the Time Stamping Authority (TSA) transmitted with a timestamp in accordance with RFC 3161 standard. A token is obtained. This token is used to validate the signature for a specific period of time. cryptographic proof of its existence at that point It constitutes. 17 Step 3 – OCSP Verification and CRL Query: During Signing Validity status of the certificate used, Online Real-time via Certificate Status Protocol (OCSP) This is how it is queried. In cases where the OCSP service is inaccessible... The system automatically creates a CRL (Certificate Revocation List). It proceeds to the inquiry. Both answers are part of the verification chain. It is processed in a way that preserves its integrity. Step 4 – Placing LTV Data into the PDF Signature Dictionary: OCSP response, CRL list, timestamp token and full certificate chain; PDF signature dictionary's DSS (Document The Security Store section complies with the ETSI EN 319 132 standard. The signature is placed in this way. This step validates the certificate's validity. technically verifiable even after its expiration date It provides security. Step 5 – Signature Dictionary Integrity Check: All LTV data Once installed, the system will configure the structure of the PDF signature dictionary. Verifies integrity; detects missing, erroneous, or inconsistent data. When this happens, an error log is created and the relevant step is repeated. It is run. Step 6 – Archive Timestamp: Long term signature in order to meet archiving requirements an archive containing all LTV data added to the dictionary time An archive timestamp is created and stored in the PDF structure. This step is added to fully complete the PAdES-LTV profile. It ensures that it is met. 8. ASYNCHRONIC LOAD DISTRIBUTION MECHANISM The centralized signing engine included in the invention; high-volume system performance in corporate signing scenarios asynchronous load distribution algorithm (124) in order to protect 18 It operates. This mechanism consists of the following components: It consists of: Request Queue: Signature and other information transmitted to the system. Verification requests are categorized by priority level (critical, high, normal) They are classified accordingly and added to the processing queue (126). The queue its structure, the system for simultaneous high-volume demands in a way that will prevent it from depleting its resources It is structured. Dynamic Resource Allocation: The system allocates resources based on the instantaneous processing load. dynamically create instances of the signing engine. It scales up when the processing load exceeds a defined threshold. When it is released, new engine prototypes are automatically put into operation. unnecessary instances are closed when the load decreases. Waste of resources is prevented. Asynchronous Response Mechanism: When the signing process is complete The result is a synchronous response to the system that made the call. Instead, it is transmitted via a webhook or callback mechanism. This approach; the signing process of the calling system by waiting for it to complete, it prevents it from being blocked and the system It shortens response times overall. Transaction Monitoring and Error Management: Every signing and verification the transaction with a unique transaction ID being monitored; failed operations can be reconfigured. automatically according to the retry policy It is repeated. Exceeding the specified number of retries. The processes are added to the dead-letter queue and the system The notification is sent to the manager. 19 9. MULTI-TENANT AND WHITE-LABEL ARCHITECTURE The system described in the invention involves multiple institutions operating from the same central location. many that allow sharing of signing engine infrastructure It supports tenant architecture (128). This architecture It has the following technical specifications: Tenant Isolation: Signing sessions for each institution, certificate pools, audit records, and configuration The parameters are logically isolated from each other. Data from one organization, an example of another organization's signing engine. inaccessible by. Corporate Identity Customization (White-Label): For each institution an independent interface identity (logo, color palette, language, endorsement) (text template) can be defined. This customization; without affecting the functionality of the central signing engine It is only implemented in the presentation layer. Independent Policy Management: Each tenant organization must have; Types of certificates that can be used, biometric verification. obligation, session timeout periods and audit log independent for parameters such as retention policies It is possible to have configuration profiles. Centralized Monitoring and Reporting: All tenant transactions. data; centralized control while maintaining tenant isolation and are collected in the reporting panel (130), authorized system The company provides its managers with the opportunity for consolidated reporting. 10. STATELESS ARCHITECTURE AND SETTLEMENT MANAGEMENT The central signing engine included in the invention; Stateless in terms of scalability and fault tolerance. It is built upon a (non-contextual) architecture. In this design: Each signature request is independent of previous requests. It is processed independently. Session state is located within the signing engine. no; an encrypted message carried by the requesting system It is held within the session token (JWT / OAuth2). Failure of any engine instance In this case, requests are automatically transferred to another instance. It is being redirected; in this way, there is a single point of failure. The risk of failure is eliminated. Horizontal scaling; motor samples without requiring application-specific configuration changes It allows it to be put into operation. 11. SECURITY ARCHITECTURE AND ATTACK SURFACE MANAGEMENT The security architecture of the system described in the invention; the attack surface (attack surface) minimized with layered security measures. In order to achieve this, the following technical mechanisms are combined: It is implementing: Communication Security: All-layer communication is TLS 1.2. or is encrypted with a higher protocol. Certificate fixing (certificate pinning) is applied to the man in the middle (man-in-the- Middle-range attacks are being prevented. Client-Side Security: Thanks to zero-footprint architecture. no persistent data regarding the signing process on the user device not abandoned; the sandbox environment closes when the session ends. It is cleaned automatically. 21 Authentication and Authorization: System access; Multi-factor authentication via OAuth2 / OpenID Connect protocols. It is secured with authentication. Each API call with a short-lived access token It is authorized. Cryptographic Integrity: Used in the signing process. cryptographic algorithms (RSA-2048 / 4096, ECDSA P-256 / P-384, (SHA-256 / SHA-512) in accordance with current standards is being restructured; weak algorithm usage system It is blocked by [the organization / institution]. Audit Traceability: Every access to the system, each signing and verification process performed; time as an immutable control record It is stored in a stamped form. 12. PREFERRED APPLICATION FORMS The invention is limited to, but not limited to, the following examples. can be implemented in non-existent application scenarios It is of the following nature: First Application Method – Banking Sector: BDDK (Banking Regulation and Supervision Agency) in financial institutions subject to regulations, to customers submitted loan agreement, collateral document and power of attorney video signing and biometric verification for documents such as these A qualified electronic signature application supported by this. In this scenario, the document content is stored in the bank's data center; Only document summary and signature metadata cloud coordination. It is shared with the service. Second Application Method – Public Institutions: E-government integrated with its infrastructure, citizens' official applications, 22 statements and agreements without any addendums without requiring a qualified web browser Signing with an electronic signature. Smart certificate filtering. the algorithm, the citizen's e-ID card or mobile signature It automatically detects and directs the process. Third Application Method – Healthcare Sector: Patient consent forms, doctor's reports and prescriptions; health information through a central signing engine integrated with the system Signing in PAdES-LTV format and long term archiving in a verifiable manner. Fourth Application Form – Insurance Sector: Policy, Claim documents such as the inspection report and payment instructions; insurance with the company's existing customer management system (CRM / ERP) integrated via the wrapper layer by connecting to the central signing engine, it is qualified. Signed with an electronic signature. In this scenario, biometric. The verification layer proves the insured's identity and will. This is introduced as an additional legal safeguard. Fifth Application Method – Corporate Human Resources Processes: Employment contract, confidentiality agreement, fringe benefits request forms and disciplinary documents; the institution's human resources Centralized signing engine integrated with the resources information system. through, employees do not need any additional software Signing through their own devices without installing anything. Very Tenant-based architecture; different companies belonging to the same holding company independent of the same infrastructure as their own corporate identity profiles It allows it to be used in this way. Sixth Form of Application – Notary Offices and Law Offices: Legal documents such as power of attorney, title deed transfer, and inheritance certificate. 23 documents; video signing and multi-layered biometrics qualified electronic supported by a verification mechanism signed and long-term in PAdES-LTV format archiving in a valid format. In this scenario Biometric records; for use in court in potential legal disputes. an independent package of evidence that can be presented that has probative value It constitutes. 13. ABBREVIATIONS AND DEFINITIONS This section contains the technical terms used in the description of the invention. and abbreviations are defined: API (Application Programming Interface): Different software enables its components to communicate with each other Standard programming interface. CAdES (CMS Advanced Electronic Signature): Developed by ETSI. defined in CMS (Cryptographic Message Syntax) format Based on an advanced electronic signature standard. CRL (Certificate Revocation List): Certificate authority revoked certificates issued by a verification list that is updated periodically vehicle. DSS (Document Security Store): For verification purposes in PDF format. where the necessary certificate, OCSP response and CRL data are stored area. ETSI (European Telecommunications Standards Institute): Electronic signature standards (PAdES, CAdES, XAdES) Published by the European Telecommunications Standards Institute. 24 iFrame (Inline Frame): A standalone document within a web page. An HTML component used to create the workspace; within the scope of the invention. It is used as an isolated sandbox environment. JWT (JSON Web Token): Secure information exchange between parties. used for the transfer of digitally signed compacts a token format. LTV (Long Term Validation): Electronic signature; certificate verification even after the validity period has expired providing OCSP / CRL and timestamp data to the signature structure. Including verification profile. Multi-Tenant: Multiple entities operating in the same building. software infrastructure; data and configuration isolation An architectural model that can be shared while being preserved. OCSP (Online Certificate Status Protocol): A certificate's status used to check current validity status online protocol. PAdES (PDF Advanced Electronic Signature): Developed by ETSI. Defined, advanced electronic signature based on PDF format. standard; long-term verifiability with LTV profile is winning. postMessage API: From various sources in web browsers (origin) secure messaging between incoming iFrames. It provides a standard browser programming interface. RFC 3161: Defines the timestamp protocol and the process of stamping data. cryptographic existence at a specific point in time a standard that proves it. Sandbox: A space surrounding an application or component. It is operated in isolation from the system, in a safe and restricted environment. environment. Stateless Architecture: The server's session with the client... It does not store the status in local memory; each request is independent and Architecture that is processed without dependence on previous requests approach. TSA (Time Stamping Authority): Complies with RFC 3161 standard. timestamp token issued by the authorities authority. USB Token / Smart Card: The user's private key and securely storing the electronic signature certificate portable hardware device. White Label: A label that certifies a software product to the purchasing organization. can be presented with its corporate identity (logo, colors, language) privatization model. XAdES (XML Advanced Electronic Signature): Developed by ETSI. Defined, advanced electronic signature based on XML format. standard. Zero-Footprint: After the signing process is complete. temporary file, cache data or on user device Client architecture that leaves no library remnants. Law No. 5070: Legal framework for electronic signatures in Türkiye validity, qualification certificate requirements and certificate Law regulating the obligations of service providers. 26

Claims

1. Different software architectures and operating systems third-party systems on the client side any browser plugin, local library, or High-quality without requiring hardware dependency. a center that provides electronic signature capabilities It is an electronic signature system; its feature is:  Accessible via a standard web browser, It operates independently of the platform and browser, and is client-based. the most easy device to install without any software a small interface component (101),  Third-party hosting of the interface component in question completely isolated from application memory employee, signature data and cryptographic session preventing information from leaking into the main application memory and type-safe via postMessage protocol at least one iFrame-based sandbox that provides messaging environment (102),  Signing in PAdES, CAdES and XAdES formats, time stamping, OCSP validation, CRL querying, and long Processing period validation (LTV) data its functions from ready-made third-party libraries running independently, operating on a stateless architecture and the most supporting multi-tenant structure a small central signature engine (104),  The data to be signed must not be transmitted outside the corporate network. only central signing of the document hash transferred to the engine and signing coordination an additional VPN component over cloud infrastructure at least one hybrid data point that is run without requiring stream layer (112), 27  With different programming languages ​​and software frameworks enhanced third-party systems, central a standard RESTful API or web signature engine the most effective way to connect via the service interface a small layer of wrapping and abstraction (108) It is to have.

2. According to claim 1, it is a system, and its characteristic is; the system in question also; signing and verification transmitted to the system. processing requests by classifying them according to priority level a signing engine that queues up data based on the instantaneous transaction load. dynamically scaling and signing instances transmitting results via webhook or callback mechanism at least one asynchronous load distribution mechanism (124) It is to have.

3. The system is defined according to claim 1 or 2, and its characteristic is; The system also allows multiple institutions to use the same central office. enabling it to share its signing engine infrastructure, Signing sessions and certificate pools for each institution. and audit records logically separated from each other isolating and independent structuring for each institution at least one or more that allow the profile to be defined It has the component of tenant architecture (128).

4. The system is based on any of claims 1 to 3, The feature is that the system in question also belongs to each institution. interface identifier (logo, color palette, language, confirmation text) (template) functionality of the central signing engine unaffected, only in the presentation layer At least one customizable white-label configuration It has component (132).

5. The system is based on any of claims 1 through 4, The feature is that the system also includes every step taken towards the system. access, each signing and verification performed. the transaction is immutable and timestamped 28 stored in a way that maintains tenant isolation at least one audit that enables centralized reporting It has the registration and reporting component (130).

6. The system is based on any of claims 1 through 5, This system also features OAuth2 / OpenID. Multi-factor authentication via Connect protocols. providing validation and short-lived every API call at least one identity authorized with an access token verification and authorization component (134) It is to have.

7. Any software installation on the client side. not requiring, carried out through hybrid architecture is a central electronic signature method. The methods are as follows:  The signing request from a third-party system, through the layer of wrapping and abstraction by converting it to a standard data format the request receiving step,  The document or data to be signed must be within the organization's network. only the document hash is kept encrypted. Centralized signing via communication tunnel the document summary transfer step where it is transmitted to the engine,  Document summary of the central signing engine with the user's electronic signature certificate signed, OCSP verification and timestamp signing and carrying out the acquisition simultaneously verification step,  OCSP response, CRL list, timestamp token and DSS PDF signature dictionary of the complete certificate chain section in accordance with ETSI EN 319 132 standard the LTV data placement step where it is placed, 29  After the signing process is complete, the client temporary files, cache data or on your device the session without leaving any library remnants all temporary data has been securely cleaned by including a zero-residue termination step central electronic signature characterized method.

8. The method according to claim 7 is also; including all LTV data added to the signing dictionary an archive timestamp Archive time when it was created and added to the PDF structure It is characterized by including the stamping step.

9. The method according to claim 7 or 8, and the method in question Furthermore, in situations where the OCSP service is inaccessible, the system... it automatically switched to CRL querying and both the response will maintain the integrity of the verification chain by including the backup verification step processed in this way It is characterized.

10. The method according to any of claims 7 to 9. This method also applies to each signing session. a unique nonce value is generated and transmitted each message undergoes source verification and type-safe validation. the session security step that was filtered It is characterized by its inclusion.

11. The method according to any of claims 7 to 10. The method in question also includes the call for the signing result. Instead of a real-time response from the system, a webhook or that it is transmitted via a callback mechanism and each transaction with a unique transaction ID by including the asynchronous result transmission step that is being monitored It is characterized.

12. The method according to any of claims 7 to 11. the method in question is a three-layered (three-) compliant method with the Banking Regulation and Supervision Agency (BDDK). tier) security architecture, additional VPN or private network infrastructure at the software level without requiring any components. It is characterized by being implemented in a way that meets the requirements.

13. In the electronic signing process, the signatory cryptographically proving one's identity and will It is a multi-layered biometric authentication method. The subject matter and method are as follows:  A system-generated signature specific to the transaction to be signed. and an approval that cannot be changed by the user the step in which the text is produced,  The user must read the aforementioned consent text aloud. recording in real-time video and audio the initiation step,  Speech recognition engine for reading aloud (120) it is converted into text through the system compared with the approval text produced by; the agreement rate is below the specified threshold value if it remains, the process will be automatic the text validation step that was terminated,  The recorded voice sample belongs to the user beforehand. with a created voice biometric profile (voiceprint) by comparing and verifying user identity voice biometric verification step,  Voice analysis score, video recording summary, and text matching the ratio of the electronic signature's cryptographic envelope signed and included, person-device-transaction only one verifiable record of the trilogy the biometric sealing step taken,  Immutable control record of all biometric data archiving as a timestamped file multilayered, characterized by including the step. Biometric verification method. 31 14. The method according to claim 13, and the method in question... also; two consecutive failed verification attempts then the session was automatically terminated for security reasons. that it was terminated and recorded in the incident log It is characterized by including the session termination step. It is done.

15. The method is in accordance with claim 13 or 14. The method also involves the signing process. device fingerprint data the device where the biometric record is added and archived It is characterized by including the identification step.

16. Method according to any of claims 13 to 15. and the biometric data in question; electronic signature archived in encrypted form within a cryptographic envelope against unauthorized access and modification attempts It is characterized by being protected.

17. Method according to any of claims 13 to 16. and the approval text in question; pertains to the transaction to be signed. unique identifier, transaction amount, date and party automatically by the system to include the information It is produced as and presented to the user in read-only format. It is characterized by how it is presented.

18. Multiple electronic signature certificates in environments that accommodate, legally compliant certification automatic without requiring user intervention Smart certificate filtering that identifies and selects certificates. The method in question is as follows:  Smart card, USB token and software connected to the system scanning certificate repositories and all available ones certificate inventory where certificates are listed step,  Each certificate must comply with the Electronic Signature Law No. 5070. and qualified electronics within the scope of ETSI TS 102 280. 32 whether it has the status of a signature certificate, a trusted certificate service provider whether it was arranged by and the key key usage in the signing process the level of quality at which suitability is evaluated verification step,  The validity period of each certificate, including cancellation status in real time via OCSP or CRL as questioned and usage restrictions the instant validity check step where it is checked,  Level of quality, validity period and intended use a weighted score according to the criteria the model applied and the one that received the highest score automatically for the certificate signing process weighted scoring and automatic selection determined step,  The automatically selected certificate's corporate policy when necessary, via the user's confirmation screen provided that, otherwise no user intervention is required. conditional on the continuation of the process without stopping It is characterized by including a user confirmation step. The smart certificate filtering method used.

19. The method is according to Claim 18 and is weighted accordingly. parameters of the scoring model; corporate policy it is dynamically read from the file and the institution administrator It is characterized by the fact that it can be structured by [the system / organization].

20. The method is according to claim 18 or 19. The method also includes each certificate selection performed. the process, the reason for the selection and evaluation unchangeable control along with its parameters by including the election registration step that was recorded in the register It is characterized. 33 21. Method according to any of claims 18 to 20. and the method in question also has an insufficient level of quality, Expired or canceled certificate detection When this happens, an explanatory warning is sent to the user and the use of the certificate in the signing process insufficient certificate, blocked by the system It is characterized by including a blocking step.

22. Method according to any of claims 18 to 21. and if the OCSP service in question is inaccessible The system automatically switches to CRL querying and both types of responses are used as input to the scoring model. It is characterized by its inclusion. 34