Uwp application extension peripheral device calling method, system and medium

Abstract

The application provides a UWP application extension peripheral device calling method, system and medium, wherein the method comprises the following steps: a UWP hybrid application layer sends a peripheral device calling request to an API layer; the API layer completes communication message conversion and message encryption of interface calling and transmits the message to a device middleware service layer; the device middleware service layer performs message decryption and task matching, and then converts the task into an SP structure body, calls a device SP drive layer; the device SP drive layer completes calling response, and returns an execution result to the device middleware service layer according to a synchronous or asynchronous calling mode; the device middleware service layer performs message encryption on the returned execution result and returns the execution result to the API layer; the API layer performs decryption and message analysis and then responds, and returns a response result to a UWP platform; and the UWP platform responds to a business component according to the return result of the API layer. The problem that a UWP application cannot directly complete calling of a vendor SP is solved.

Description

UWP Application Extension Peripheral Calling Methods, Systems, and Media Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a method, system, and medium for calling extended peripherals in UWP applications. Background Technology

[0002] The Universal Windows Platform (UWP) in Windows 10 is not designed for a single terminal, but can run simultaneously on devices running Windows 10 and above, such as Windows 10 Mobile, Surface (Windows tablets), PCs, Xbox, and HoloLens. UWP differs fundamentally from traditional PC .exe applications and mobile apps. UWP applications have the following characteristics: high security (users must authorize access to all device resources and data before access); scalability; wide adaptability (develop once, run on all Windows 10 and above devices); sustainable development; high interactivity; and high compatibility (can be programmed using C#, C++, Visual Basic, and Javascript). These characteristics make UWP a powerful tool for creating client applications, favored not only in personal consumer products but also, and especially, in high-security financial self-service applications. However, in the development of front-end applications for financial self-service applications, it is necessary to call dozens of peripherals such as card readers and ID cards. For such peripheral calls, various manufacturers often adopt SP methods that comply with WOSA-XFS or PISA specifications. During the call, access and reading / writing of the registry, system protected directories, and system protected ports are involved. At the same time, it is necessary to extensively use all common system API interfaces and various font libraries such as GB18030. However, due to the security requirements of UWP and the limitations of its platform itself, it can only access a few specified folders and a few specified registry paths, namely the application's own installation path and other externally shared download directories, and generally only supports partial system API calls. Therefore, UWP applications have the problem of not being able to access commonly used SP directories and registry paths and cannot directly complete calls to vendor SPs. Summary of the Invention

[0003] This invention provides a method, system, and medium for UWP application to call extended peripherals. The method solves the problems that UWP applications cannot access common directories and registry paths of SPs and cannot directly call vendor SPs by using high privileges for encrypted socket communication on the host and system services. Furthermore, the method encrypts data throughout the peripheral call process to ensure the security of data transmission.

[0004] In a first aspect, the present invention provides a method for invoking extended peripherals in a UWP application, comprising,

[0005] S1: The UWP hybrid application layer receives the peripheral interface call request initiated by the UWP platform business component, and then sends the peripheral call request to the UWP-API layer;

[0006] S2: The UWP-API layer completes the conversion and encryption of communication messages for interface calls, and transmits the encrypted messages to the device middleware service layer;

[0007] S3: After receiving the communication message, the device middleware service layer decrypts the message, performs task matching on the decrypted message, and then converts the task into an SP structure to call the device SP driver layer.

[0008] S4: The device SP driver layer completes the call response and returns the execution result to the device middleware service layer according to the synchronous or asynchronous call method;

[0009] S5: The device middleware service layer encrypts the returned execution result and returns it to the UWP-API layer;

[0010] S6: The UWP-API layer decrypts and parses the message, then responds and returns the response result to the UWP platform;

[0011] S7: The UWP platform responds to business components based on the results returned by the UWP-API layer.

[0012] Furthermore, before S1, it also includes:

[0013] When the device boots up and enters the Windows system, the device middleware service layer starts first, and begins listening on all communication ports;

[0014] After entering the Windows system, the UWP application starts automatically and loads the UWP-API layer, and initializes the UWP-API layer; during initialization, the UWP-API layer synchronously starts the key update process with the socket communication server, which is unique during this connection.

[0015] The key update process includes:

[0016] Step 1: Perform key initialization by storing the initial asymmetric key's public and private keys on the client and server sides of the socket communication, respectively.

[0017] Step 2: The client generates a multi-byte random number, encrypts the generated random number using its public key, and transmits the encrypted data to the server.

[0018] Step 3: The server uses its own private key to decrypt. If decryption is successful, the decryption result is sent to the client and proceeds to Step 4; otherwise, Step 8 is executed.

[0019] Step 4: The client generates a new multi-byte working key, and uses a random number to encrypt the working key using SM4 to obtain the encryption result;

[0020] Step 5: Calculate the hash value of the working key from Step 4, and send the hash value and the encryption result from Step 4 to the server;

[0021] Step 6: After receiving the data, the server uses a random number to decrypt the encrypted result and calculates the hash value of the decrypted result. The calculated result is compared with the hash value passed in step 5. If the two are the same, it means that the data decryption is successful and proceeds to step 7; otherwise, proceeds to step 8.

[0022] Step 7: Store the decryption result as the latest working key, transmit the successful key update result to the client, and complete the key update process;

[0023] Step 8: If the data decryption is inconsistent or fails, or the key update fails, the failure result is reported back to the server, and the update process ends.

[0024] Furthermore, S2 specifically includes:

[0025] When the UWP-API layer receives a request to call the peripheral interface, it assembles the module name, function name, function type, input parameters, and pipeline ID into a task structure.

[0026] The UWP-API layer calls a unified serialization function to serialize the task structure into a socket communication message;

[0027] The encryption / decryption suite is called in the UWP-API layer to encrypt the message using the encryption key;

[0028] The UWP-API layer calls the socket communication component to send encrypted messages to the device middleware service layer through the socket client.

[0029] Furthermore, S3 specifically includes:

[0030] After receiving a communication message, the socket communication server in the device middleware service layer calls the encryption and decryption suite to decrypt the message. The decrypted message is then compared and matched by module name and socket connection handle. The task that matches successfully is dispatched and added to the input task queue of the corresponding module.

[0031] The device middleware service layer obtains the task name and corresponding execution parameters according to the first-in-first-out principle, calls the processing function in the module class to process it, and completes the task processing thread.

[0032] The device middleware service layer converts the input parameters into an SP structure, and then calls the SP interface in the device SP driver layer.

[0033] Furthermore, S4 specifically includes:

[0034] If it is a synchronous call method (such as a key query interface):

[0035] During startup and operation, the device SP driver layer accesses various system file directories and registry paths as needed, calls hardware instructions to complete hardware actions, and returns the interface execution results.

[0036] If it is an asynchronous call (such as a password input interface):

[0037] After the device SP driver layer receives the asynchronous interface, it sends the execution instruction to the device SP driver layer processing thread and adds the result of the asynchronous interface to the output queue.

[0038] During startup and operation, the device SP driver layer accesses various system file directories and registry paths as needed, and calls hardware instructions, waiting for the user to perform peripheral module operations (such as key input). Each user peripheral module operation triggers a corresponding process event (such as each key press triggers a key event in the device SP driver layer). The device SP driver layer synchronously sends process events to the SP manager when the user operates the peripheral. After the user completes the peripheral operation, the device SP driver layer sends an asynchronous completion event to the SP manager (such as a password input completion event).

[0039] The device middleware service layer accesses the system message queue through the manager, obtains process events (such as key events) and asynchronous completion events, and puts them into the output message queue of the module object that matches the task in S3.

[0040] In the output thread of the device middleware service layer, a message task is retrieved from the output queue according to the first-in-first-out principle and then enters S5 sequentially.

[0041] Furthermore, S5 specifically includes:

[0042] The device middleware service inputs the results and output parameters returned by the device SP driver layer or the execution results of the device middleware service itself into a unified structure conversion function, which then converts them into a unified task structure.

[0043] In the device middleware layer, the socket server calls a unified serialization function to serialize the task structure into a socket communication message;

[0044] In the device middleware layer, the socket server calls the encryption / decryption component to encrypt the message and sends the encrypted message to the UWP-API layer through the socket server.

[0045] Furthermore, S6 specifically includes:

[0046] The UWP-API layer calls the encryption / decryption components and the unified deserialization function to complete the socket message parsing. After matching the function name and serial number of the peripheral call request, it assigns the obtained parameters and results to the output parameters and return of the calling interface in S2.

[0047] Furthermore, S7 specifically includes:

[0048] If it is a synchronous call method:

[0049] The UWP platform object responds based on the return value of the UWP-API layer. If the return value is 0, the OnComplete callback of the business component is executed.

[0050] If it is an asynchronous call:

[0051] The UWP platform object returns 0 based on the execution result parameter in the asynchronous completion event of the UWP-API layer, and executes the OnComplete callback of the business component. If the return value is not 0, the OnError callback of the business component is executed. Process events and asynchronous return results will call back the OnProcess of the business component to notify the business component.

[0052] Secondly, the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the UWP application extended peripheral invocation method as described above.

[0053] Thirdly, the present invention provides a UWP application extended peripheral calling system, comprising:

[0054] UWP Hybrid Application Layer Module, UWP-API Layer Module, Device Middleware Service Layer Module, Device SP Driver Layer Module;

[0055] The UWP hybrid application layer module is used to build application processes based on the UWP platform framework. The UWP platform itself provides peripheral integration call objects JSFactory for peripherals, which call the interface library of the UWP-API layer to make peripheral calls.

[0056] The UWP-API layer module is used to convert and encrypt the socket communication messages from the UWP platform interface calls, and then transmit the encrypted messages to the device middleware service layer module. It also returns the execution result of the device middleware service layer to the UWP hybrid application layer module.

[0057] The device middleware service layer module is used to immediately start listening to all UWP-API layer ports after power-on, waiting for connections from various UWP-API layer socket clients; after receiving communication messages, it decrypts the messages, performs task matching on the decrypted messages, and then converts the tasks into SP structures to call the device SP driver layer; the returned execution results are encrypted and then returned to the UWP-API layer.

[0058] The device SP driver layer module is used to respond to the call instructions sent by the device middleware service layer module, and return the execution results to the device middleware service layer accordingly, depending on whether the call method is synchronous or asynchronous.

[0059] This invention provides a method, system, and medium for extending peripheral device access in a UWP application. The method utilizes encrypted socket communication on the local machine to convert all complex function interface calls into messages and transmit them to the device middleware service. The device middleware service is then made into a Windows system service, and its system service attributes are used to obtain maximum access permissions. Simultaneously, encrypted custom protocol socket communication ensures data transmission security and decouples the process from the UWP application. This maximizes the peripheral devices that the UWP can access while shielding the application from the impact of peripheral device anomalies. By combining encrypted socket communication and system services, the method achieves a balance between UWP security and extended peripheral device access, providing a reliable solution for applying the UWP platform to the financial self-service field. Attached Figure Description

[0060] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0061] Figure 1 is a diagram of the overall framework for peripheral device access in a Windows front-end UWP application provided by the present invention.

[0062] Figure 2 is a key update timing diagram provided by the present invention;

[0063] Figure 3 is a timing diagram of synchronous peripheral interface call provided by the present invention;

[0064] Figure 4 is a timing diagram of asynchronous peripheral interface calls provided by the present invention;

[0065] Figure 5 is a timing diagram of an implementation example provided by the present invention. Detailed Implementation

[0066] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be described in detail below. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other implementations obtained by those skilled in the art without creative effort are within the scope of this invention.

[0067] This invention provides a method, system, and medium for extending peripheral device invocation in UWP applications, applicable to all front-end applications using the UWP framework. The recommended driver standard is the SP form of the PISA or WOSA-XFS standard. Taking a self-service device front-end application of a certain bank as an example, Figure 1 shows the overall framework diagram of peripheral device invocation under a Windows front-end UWP application, specifically including a UWP hybrid application layer, a UWP-API layer, a device middleware service layer, and a device SP driver layer.

[0068] UWP Hybrid Application Layer: This layer builds application processes based on the UWP platform framework. The UWP application uses the Microsoft Edge browser as its core and .NET as its secondary development language platform. The UWP platform itself provides a peripheral integration call object, JSFactory, for peripheral JavaScript, and then makes peripheral calls by calling the C++ version of the UWP-API layer's interface library.

[0069] UWP-API Layer: The UWP-API layer is a C++ dynamic library compiled according to the UWP platform's specified SDK version (which can be achieved by adding a specified version of the runtime library to the compilation project). The C++ dynamic library must meet the following requirements: (1) The functionality should be as simple as possible, and all system APIs used must be supported by the UWP platform; (2) It should complete the conversion of UWP platform interface calls to socket communication messages, that is, it should have socket client functionality; (3) It should complete the encryption and transmission of messages. When writing the API layer, try to use the minimum functional interface, and select the / ZW mode that supports UWP during compilation.

[0070] Device Middleware Service Layer: As the socket server for each UWP-API layer interface library, the device middleware service layer's process is registered as a Windows system service. After booting, it can quickly start listening to all UWP-API layer interface library ports, waiting for connections from various API library socket clients. It performs functions such as socket communication, message encryption and decryption, data serialization and deserialization, message classification, multi-threading, and multi-queue concurrent execution. It provides socket communication message interfaces to the UWP-API layer. For the device SP (Service Provider) driver layer, the device middleware service layer converts the API interface into calls to multiple SP execution interfaces and uses its system service attributes to start the processes of each SP as a system administrator. This gives the module SP processes maximum file read / write and registry read / write permissions, breaking through the UWP hybrid application layer's access restrictions on files and the registry.

[0071] Device SP driver layer: It receives application layer instructions through the SP's API interface, transforms the application instructions into SP execution commands, and completes the specific operation of the device through the USB port and serial port; according to the differences in synchronous and asynchronous calling methods of the middleware service layer, it returns the execution results and process events accordingly.

[0072] To prevent the leakage of user information data during the entire peripheral device access process, and to encrypt and decrypt the data accordingly, this invention uses a key update mechanism for data encryption and decryption. By leveraging local encrypted socket communication and high-privilege system services, the problem of UWP applications being unable to directly call vendor service providers (SPs) is solved. Socket communication is used to achieve inter-process communication between the UWP application and the device middleware service, while simultaneously decoupling peripheral device access from the application layer, enhancing the robustness of the UWP application and the security of data transmission.

[0073] The message structure for data socket communication is shown in Table 1. Its message structure includes the message structure for sending data and the message structure for receiving data. The meaning of each field in the message is explained in Table 2.

[0074] Table 1 Message Structure

[0075]

[0076] Table 2 Explanation of the meaning of each field in the message.

[0077]

[0078] In actual program interface calls, each task data exists as a structure. Therefore, each task sending requires serializing the structure into the sent message in Table 1. Each task receiving requires deserializing the received message according to the parameters in Table 1 and converting it into the structure required by the interface. For example, the message used in the key update process has a fixed module name as the encryption component name (SoftEncypt), and the key update message is not encrypted but transmitted directly in plaintext. All key update-related interfaces are directly dispatched to the encryption component.

[0079] The key update mechanism used in data encryption and decryption is shown in Figure 2. The initial keys of the client and the server are a public-private key pair. The core of the key update mechanism is to use a highly complex asymmetric key to update the key of SM4 (a Chinese national cryptographic symmetric encryption algorithm, an iterative block cipher algorithm), which has a slightly lower complexity and faster computation speed.

[0080] The specific implementation steps of the key update mechanism are as follows:

[0081] Step 1: Perform key initialization by storing the initial asymmetric key public key (PK) and private key (SK) on the client and server sides of the socket communication respectively.

[0082] Step 2: The client generates a 16-byte random number Radom, encrypts the generated random number using its public key, and transmits the encrypted data to the server.

[0083] Step 3: The server uses its own private key to decrypt the code. If decryption is successful, the server sends the decryption result to the client and proceeds to Step 4; otherwise, it proceeds to Step 8.

[0084] Step 4: The client generates another 16-byte working key wk, and uses the random number Radom to encrypt the working key wk using SM4 to obtain the encrypted result EnData.

[0085] Step 5: Calculate the hash value of the working key from Step 4, and send the hash value of this step and the encryption result EnData from Step 4 to the server.

[0086] Step 6: After receiving the data, the server uses the random number Radom to decrypt the encrypted result EnData to obtain the decrypted result DecData. The server then calculates the hash value of the decrypted result DecData and compares the calculated result with the hash value sent in step 5. If the two match, the data decryption is successful, and the server proceeds to step 7; otherwise, the server proceeds to step 8.

[0087] Step 7: Store the decryption result DecData as the latest working key wk, and transmit the result of the successful key update to the client. The key update is now complete.

[0088] Step 8: If the data decryption is inconsistent or fails, it means that the key update has failed. The failure result is fed back to the server, and the key update process ends.

[0089] Each time the server receives a connection request from a client, it saves the corresponding socket connection handle and uses it as the client ID. When the server receives a message, it first checks whether the encryption key wk corresponding to the socket connection handle exists. If it does not exist, the server can only accept the key update action corresponding to the socket handle, and all other actions will return failure. If wk exists, the server will first use wk to call the decryption component to complete the data decryption, and dispatch it to the different module middleware objects in the device middleware service layer for specific execution according to the module name in the decrypted message.

[0090] The specific interface calling method of the peripheral module can be selected as either synchronous or asynchronous interface calling method according to different scenario needs, as described in Example 1 and Example 2 respectively.

[0091] Example 1

[0092] When using the synchronous interface call method, the interface call sequence is shown in Figure 3. In this embodiment, the query interface for whether the key of the password keyboard exists is taken as an example. The specific implementation steps are as follows:

[0093] Step 1: After the device is powered on and enters the Windows system, the device middleware service starts as a system service first, and starts listening on all socket communication ports.

[0094] Step 2: After entering the system, the UWP application starts automatically and loads the UWP-API layer, and initializes the UWP-API layer; during initialization, the UWP-API layer synchronously starts the key update process with the socket communication server, which is unique during this connection.

[0095] Step 3: After opening all peripherals during the application loading process, the key query interface in the password keyboard UWP-API layer will be called immediately to query whether the master key in the machine has been downloaded.

[0096] Step 4: The UWP-API layer receives the key query interface and assembles the password keyboard name, key query method name, function type, input parameters, etc. into a task structure.

[0097] Step 5: In the UWP-API layer, a unified serialization function is called to serialize the task structure into a socket communication message.

[0098] Step 6: In the UWP-API layer, call the encryption / decryption suite and use the encryption key to encrypt the message.

[0099] Step 7: The UWP-API layer calls the socket communication component to send the encrypted message from Step 6 to the device middleware service layer through the socket client. If the message is successfully sent, proceed to Step 8; otherwise, the interface returns an internal communication error code -15 and proceeds directly to Step 17.

[0100] Step 8: The key query interface in the UWP-API layer blocks and waits for the result to be returned. If the query result is not received within the specified timeout period, the execution result is a timeout, and the interface returns a timeout error code -48, and proceeds directly to step 17; otherwise, proceed to step 9.

[0101] Step 9: After receiving the communication message, the socket server in the device middleware service layer calls the encryption / decryption suite to decrypt the message. The decrypted message is compared and matched by module name and socket connection handle. If the match is successful, the task is dispatched and added to the input task queue of the corresponding module, and then proceed to step 10; otherwise, software error -53 is returned, and then proceed to step 13.

[0102] Step 10: The task processing thread of the password keyboard module instance (instances distinguished by module name) in the device middleware service layer obtains the task name and corresponding execution parameters according to the first-in-first-out principle, and calls the processing function in the module class for processing.

[0103] Step 11: The socket server in the device middleware layer converts the input parameters into an SP structure and calls the corresponding SP interface in the device SP driver layer. If there is no corresponding SP interface, it returns failure directly and proceeds to step 13; otherwise, it proceeds to step 12.

[0104] Step 12: During startup and operation, the device SP driver layer accesses various system file directories and registry paths as needed, calls hardware instructions to complete hardware actions, and returns the interface execution results.

[0105] Step 13: The device middleware service layer inputs the results and output parameters returned by the device SP driver layer or the execution results of the device middleware service layer itself into a unified structure conversion function, and converts them into a unified task structure.

[0106] Step 14: The socket server in the device middleware layer calls a unified serialization function to serialize the task structure into a socket communication message.

[0107] Step 15: The device middleware server calls the unified encryption / decryption component to encrypt the message and sends the encrypted message through the socket server. If the sending fails, the interface enters the UWP-API layer timeout handling process; otherwise, proceed to step 16.

[0108] Step 16: The UWP-API layer calls the encryption / decryption components and the unified deserialization function to complete the socket message parsing. After matching the function name and serial number ID of the key query, the obtained parameters and results are assigned to the output parameters and return of the key query interface.

[0109] Step 17: The UWP platform object executes the OnComplete callback of the business component if the return value is 0, and executes the OnError callback of the business component if the return value is non-zero. This callback will then drive the business to the next step.

[0110] Example 2

[0111] When using asynchronous interface calls, the interface call sequence is shown in Figure 4. In this embodiment, the user password input interface of the password keyboard is taken as an example, and its specific implementation steps are as follows:

[0112] Step 1: After the device is powered on and enters the system, the device middleware service is started first as a system service, and all socket communication ports are started for listening.

[0113] Step 2: After entering the system, the UWP application starts automatically and loads the UWP-API layer, and initializes the UWP-API layer; during initialization, the UWP-API layer synchronously starts the key update process with the socket communication server, which is unique during this connection.

[0114] Step 3: The application enters the common card insertion and verification process. After reading the card, it calls the password input interface of the PIN pad.

[0115] Step 4: The UWP-API layer receives the password input interface and assembles the password keyboard name, password input method name, function type (asynchronous in this case), input parameters, etc. into a task structure.

[0116] Step 5: In the UWP-API layer, a unified serialization function is called to serialize the task structure into a socket communication message.

[0117] Step 6: In the UWP-API layer, call the encryption / decryption suite and use the encryption key to encrypt the message.

[0118] Step 7: The UWP-API layer calls the socket communication component to send the encrypted message from Step 6 through the socket client. If the message is sent successfully, proceed to Step 8; otherwise, the interface returns an internal communication error code -15 and proceeds directly to Step 19.

[0119] Step 8: In the UWP-API layer, enter the password interface and wait for the interface to send the result. If no query result is received within the specified timeout period, the execution result is timeout, the interface returns timeout error code -48, and proceed directly to step 19; otherwise, proceed to step 9.

[0120] Step 9: After receiving the communication message, the socket server in the device middleware layer calls the encryption / decryption suite to decrypt the message. The decrypted message is compared and matched by module name and socket connection handle. If the match is successful, the task is dispatched and added to the corresponding task queue, and then proceed to step 10; otherwise, software error -53 is returned, and then proceed to step 15.

[0121] Step 10: The task processing thread of the password keyboard module instance (instances distinguished by module name) in the device middleware service layer obtains the task name and corresponding execution parameters according to the first-in-first-out principle, and calls the processing function in the module class for processing.

[0122] Step 11: The socket server in the device middleware layer converts the input parameters into an SP structure and calls the corresponding SP in the device SP driver layer. If there is no corresponding SP, it will directly return failure and put this execution result into the input queue, then proceed to step 15; otherwise, proceed to step 12 for specific execution.

[0123] Step 12: After the device SP driver layer receives the asynchronous interface, it sends the execution instruction to the SP processing thread and adds the result of the asynchronous interface to the output queue. Steps 15-19 are executed once. The actual interface execution process will then continue to step 13.

[0124] Step 13: During startup and operation, the device SP driver layer accesses various system file directories and registry paths as needed, and calls hardware instructions to wait for user input. Each time the user presses a key, a key event is triggered, and an asynchronous completion event is triggered when the input is completed.

[0125] Step 14: The device middleware service layer accesses the system message queue through the manager, obtains key events and asynchronous completion events, puts them into the output message queue of the password keyboard instance, and proceeds to step 15 for processing.

[0126] Step 15: The device middleware service layer output thread retrieves a message task from the output queue according to the first-in-first-out principle, and then proceeds to the serialization and decryption process below.

[0127] Step 16: The socket server in the device middleware service layer calls a unified serialization function to serialize the task structure into a socket communication message.

[0128] Step 17: The device middleware server calls the unified encryption and decryption suite to encrypt the message and sends the encrypted message through the socket server. If the sending fails, the interface enters the UWP-API layer timeout process and proceeds to step 19; otherwise, proceed to step 18.

[0129] Step 18: The UWP-API layer calls the encryption / decryption components and the unified deserialization function to complete the socket message parsing. After matching the function name and serial number ID of the key query, the obtained parameters and results are assigned to the output parameters of the user's password input and returned.

[0130] Step 19: The UWP platform object executes the OnComplete callback of the business component based on the return value of the UWP-API layer or the execution result parameter in the asynchronous completion event. If the return value is 0, the OnComplete callback of the business component is executed; if the return value is non-zero, the OnError callback of the business component is executed. Process events and asynchronous return results will call back the OnProcess of the business component to notify the business component. Through the above callbacks, the business is finally driven into the next process.

[0131] This invention, based on encrypted socket communication and Windows system service features, provides a method for calling extended peripherals in UWP applications that balances high security and high scalability. Specifically, it has the following advantages:

[0132] High scalability and security: The peripheral invocation scheme based on encrypted socket communication and Windows services provided by this invention ensures the smooth invocation of all peripherals by utilizing socket communication and Windows services, while maintaining the security of UWP by using encrypted sockets and customized messages; at the same time, it achieves a high degree of decoupling between application and peripheral invocation by using UWP-API simplification and socket communication separation, thereby improving the robustness of UWP applications.

[0133] Wide range of applications: This invention provides a peripheral device invocation scheme based on encrypted socket communication and Windows services, which can be applied to all peripheral device invocation scenarios based on the UWP platform; its upper-layer business code framework supports common technical architectures such as HTML5+JS, and can support the rapid migration of business logic code from Android or other Windows platforms. It can effectively realize synchronous and asynchronous interface calls of peripheral devices such as self-service and cash in the financial equipment field. It can be widely used in the financial equipment field and can also be extended to government affairs, taxation and other fields. An example of the application of this invention in hybrid invocation is shown in Figure 5.

[0134] Supports concurrent synchronous and asynchronous calls: Due to the channel uniqueness limitation of the SP manager, any application calling any SP synchronous interface of any module will cause exclusive access to the manager. For example, when the keypad is performing a large amount of data encryption operation and it is not completed in a short time, the SP manager is exclusively occupied by the application calling the encryption interface. At this time, other applications or other threads calling any other SP interface will report a manager blocking error. Therefore, this invention provides a complete set of synchronous to asynchronous conversion schemes, converting all synchronous interfaces to asynchronous execution, waiting for the execution result within the passed timeout period and converting it to synchronous result output, thereby completely solving the manager blocking problem caused by synchronous interface execution. The synchronous to asynchronous conversion method provides an effective middleware solution for concurrent SP calls by multiple processes and multiple threads, which is one of the foundations for supporting concurrent calls by multiple processes and multiple threads.

[0135] Supports concurrent calls across multiple processes and threads: A first-in, first-out (FIFO) input / output queue scheme is adopted to queue and thread the execution of input commands and the sending of output results, enabling concurrent response support for the overall solution. Each module has a corresponding processing class, and each module class has an independent input queue. This input queue is divided into synchronous query interface queues, synchronous execution interface queues, and asynchronous execution interface queues based on function call frequency and processing time. Each module also has its own input processing thread and formatted output queue. The server uses a socket connection temporary handle as a distinguishing identifier for each client connection on the same port. This means that all synchronous results, asynchronous results, and process events are sent out through the corresponding connection handle, avoiding the indistinguishability of events and functions with the same name when the same module's server connects to different applications.

[0136] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for calling extended peripherals in a UWP application, characterized in that, include, S1: The UWP hybrid application layer receives a peripheral interface call request initiated by a UWP platform business component, and then sends the peripheral call request to the UWP-API layer; S2: The UWP-API layer completes the communication message conversion and encryption of the interface call, and transmits the encrypted message to the device middleware service layer; S3: After receiving the communication message, the device middleware service layer decrypts the message, performs task matching on the decrypted message, and then converts the task into an SP structure to call the device SP driver layer; S4: The device SP driver layer completes the call response and returns the execution result to the device middleware service layer according to the synchronous or asynchronous call method; S5: The device middleware service layer encrypts the returned execution result and returns it to the UWP-API layer; S6: The UWP-API layer decrypts and parses the message, then responds and returns the response result to the UWP platform; S7: The UWP platform responds to the business components based on the return results from the UWP-API layer; S3 specifically includes: after receiving the communication message, the socket communication server in the device middleware service layer calls the encryption / decryption suite to decrypt the message, compares and matches the decrypted message by module name and socket connection handle, dispatches the successfully matched task and adds it to the input task queue of the corresponding module; the device middleware service layer obtains the task name and corresponding execution parameters according to the first-in-first-out principle, calls the processing function in the module class to process it, and completes the task processing thread; the device middleware service layer converts the input parameters into an SP structure, and then calls the SP interface in the device SP driver layer.

2. The UWP application extended peripheral calling method according to claim 1, characterized in that, Before S1, the process includes: When the device boots into the Windows system, the device middleware service layer starts first, enabling listening on all communication ports; after entering the Windows system, the UWP application starts automatically and loads the UWP-API layer, and initializes the UWP-API layer; during initialization, the UWP-API layer synchronously initiates a unique key update process with the socket communication server during this connection; the key update process includes: Step 1: Perform key initialization, storing the initial asymmetric key's public and private keys on the socket communication client and server respectively; Step 2: The client generates a multi-byte random number, encrypts the generated random number using its public key, and transmits the encrypted data to the server; Step 3: The server decrypts the data using its private key. If decryption is successful, the decryption result is sent to the client. If the client fails to execute the data, proceed to step 4; otherwise, proceed to step 8. Step 4: The client generates a new multi-byte working key, encrypts it using SM4 with a random number, and obtains the encryption result. Step 5: The client calculates the hash value of the working key from step 4 and sends the hash value and the encryption result from step 4 to the server. Step 6: After receiving the data, the server decrypts the encryption result using a random number, calculates the hash value of the decryption result, and compares the calculated result with the hash value passed in step 5. If they match, the data decryption is successful, and the client proceeds to step 7; otherwise, the client proceeds to step 8. Step 7: The decryption result is stored as the latest working key, and the successful key update result is transmitted to the client, completing the key update process. Step 8: If the data decryption is inconsistent or fails, the key update fails, and the failure result is fed back to the server, ending the update process.

3. The UWP application extended peripheral calling method according to claim 1, characterized in that, S2 specifically includes: receiving a peripheral call interface request in the UWP-API layer, assembling a task structure from the module name, function name, function type, input parameters, and pipeline ID; calling a unified serialization function in the UWP-API layer to serialize the task structure into a socket communication message; calling an encryption / decryption suite in the UWP-API layer to encrypt the message using an encryption key; and calling a socket communication component in the UWP-API layer to send the encrypted message to the device middleware service layer through a socket client.

4. The UWP application extended peripheral calling method according to claim 1, characterized in that, S4 specifically includes: If it's a synchronous call: During startup and operation, the device SP driver layer accesses various system file directories and registry paths as needed, calls hardware instructions to complete hardware actions, and returns the interface execution result; If it's an asynchronous call: After receiving the asynchronous interface, the device SP driver layer sends the execution instruction to the device SP driver layer processing thread and adds the asynchronous interface completion result to the output queue; During startup and operation, the device SP driver layer accesses various system file directories and registry paths as needed, calls hardware instructions, and waits for the user to perform peripheral module operations. Each user peripheral module operation triggers a corresponding process event. The device SP driver layer synchronously sends process events to the SP manager when the user operates the peripheral; After the user completes the peripheral operation, the device SP driver layer sends an asynchronous completion event to the SP manager; The device middleware service layer accesses the system message queue through the manager, obtains the process events and asynchronous completion events, and puts them into the output message queue of the module object matching the task in S3; In the output thread of the device middleware service layer, a message task is obtained from the output queue according to the first-in-first-out principle and sequentially enters S5.

5. The UWP application extended peripheral calling method according to claim 1, characterized in that, S5 specifically includes: the device middleware service layer inputs the results and output parameters returned by the device SP driver layer or the execution results of the device middleware service layer into a unified structure conversion function to convert them into a unified task structure; the socket server in the device middleware layer calls a unified serialization function to serialize the task structure into a socket communication message; the socket server in the device middleware layer calls an encryption / decryption component to encrypt the message and sends the encrypted message to the UWP-API layer through the socket server.

6. The UWP application extended peripheral calling method according to claim 1, characterized in that, Specifically, S6 includes: the UWP-API layer calls the encryption / decryption component and the unified deserialization function to complete the socket message parsing; after matching the function name and serial number ID of the peripheral call request, the obtained parameters and results are assigned to the output parameters and return of the interface call in S2.

7. The UWP application extended peripheral calling method according to claim 1, characterized in that, S7 specifically includes: If it is a synchronous call: the UWP platform object responds according to the return value of the UWP-API layer. If the return value is 0, the OnComplete callback of the business component is executed; if the return value is not 0, the OnError callback of the business component is executed. If it is an asynchronous call: the UWP platform object responds according to the execution result parameter in the asynchronous completion event of the UWP-API layer. If the return value is 0, the OnComplete callback of the business component is executed; if the return value is not 0, the OnError callback of the business component is executed. Process events and asynchronous return results will call back the OnProcess of the business component to notify the business component.

8. A UWP application extended peripheral calling system, the system being used to execute the method according to any one of claims 1-7, characterized in that, include: UWP Hybrid Application Layer Module, UWP-API Layer Module, Device Middleware Service Layer Module, Device SP Driver Layer Module; The UWP hybrid application layer module is used to build application processes based on the UWP platform framework. The UWP platform itself provides a peripheral integration call object JSFactory for peripherals, which makes calls to peripherals by calling the interface library of the UWP-API layer. The UWP-API layer module is used to convert the UWP platform interface call into socket communication messages, encrypt the messages, and transmit the encrypted messages to the device middleware service layer module. It also returns the execution result of the device middleware service layer to the UWP hybrid application layer module. The device middleware service layer module is used to immediately start listening to all UWP-API layer ports after power-on, waiting for connections from various UWP-API layer socket clients. After receiving communication messages, it decrypts the messages, performs task matching on the decrypted messages, converts the tasks into SP structures, and calls the device SP driver layer. It encrypts the returned execution result and returns it to the UWP-API layer. The device SP driver layer module is used to respond to the call instructions sent by the device middleware service layer module and returns the execution result to the device middleware service layer accordingly, depending on whether the call method is synchronous or asynchronous.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the UWP application extended peripheral invocation method as described in any one of claims 1 to 7.

Images