CN117640076A - 基于u盾的文档加解密方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本发明实施例公开了基于U盾的文档加解密方法、装置、计算机设备及存储介质。所述方法包括：获取由IO管理器转换对文件的操作请求后形成的IRP文件；获取来自应用程序的控制命令；根据所述控制命令反馈状态信息至应用程序，以由应用程序制定加解密策略，并由应用程序发送加解密策略；接收所述加解密策略；根据所述IRP文件判断对文件的操作是否是所述加解密策略中的需要加解密操作类型；若对文件的操作是所述加解密策略中的需要加解密操作类型，则利用U盾加解密技术对所述文件进行加解密，以得到处理结果。通过实施本发明实施例的方法可实现提高基于U盾的文档加解密的安全性、可靠性、适用性以及合规性。

Description

基于U盾的文档加解密方法、装置、计算机设备及存储介质

技术领域

本发明涉及计算机，更具体地说是指基于U盾的文档加解密方法、装置、计算机设备及存储介质。

背景技术

目前文档加密软件按类型上说主要是分为纯软件型和软硬结合型两种，纯软件型就是加密软件通过密钥和算法，实现对文档的加密操作，但密钥和运算是在操作系统内存里存放和完成的。软硬结合型就是加密软件通过硬件与软件结合的方式，实现加解密操作的，这类产品都是采用网络版形式的，加密密钥、敏感数据、算法、自定义算法都存储在加密服务器中的加密卡里，并且加解密运算也在加密服务器中的加密卡里完成的。

纯软件型的文档加密软件也有单机版和网络版，使用方便，应用环境不受限，但安全性以及可靠性较差，容易被破译。软硬结合型的文档加密软件只有网络版，安全型可靠性较高，但是适用性较差，使用也不方便，集中访问时容易卡顿。同时，密钥的生存、存储和运算是在加密服务器中的加密卡中完成的，而加密服务器是在机房中运行维护的，有很多潜在的安全隐患。

因此，有必要设计一种新的方法，实现提高基于U盾的文档加解密的安全性、可靠性、适用性以及合规性。

发明内容

本发明的目的在于克服现有技术的缺陷，提供基于U盾的文档加解密方法、装置、计算机设备及存储介质。

为实现上述目的，本发明采用以下技术方案：基于U盾的文档加解密方法，包括：

获取由IO管理器转换对文件的操作请求后形成的IRP文件；

获取来自应用程序的控制命令；

根据所述控制命令反馈状态信息至应用程序，以由应用程序制定加解密策略，并由应用程序发送加解密策略；

接收所述加解密策略；

根据所述IRP文件判断对文件的操作是否是所述加解密策略中的需要加解密操作类型；

若对文件的操作是所述加解密策略中的需要加解密操作类型，则利用U盾加解密技术对所述文件进行加解密，以得到处理结果。

其进一步技术方案为：所述加解密策略包括属于授权进程中打开非空非加密文件的操作，不进行加解密操作；属于授权进程中打开非空加密文件的操作，进行第一种加解密方式；属于授权进程打开空文件的操作，进行第二种加解密方式；属于非授权进程中打开非空非加密文件的操作，不进行加解密操作；属于非授权进程中打开非空加密文件的操作，进行第三种加解密方式；属于非授权进程中打开空文件的操作，不进行加解密操作。

其进一步技术方案为：所述第一种加解密方式包括将所述文件标记为读写要加解密类型，并进行加解密操作，刷新缓存；所述第二种加解密方式包括将所述文件标记为读写要加解密类型，并进行加解密操作；所述第三种加解密方式包括将所述文件标记为读写要加解密类型，并进行加解密操作，清空缓存。

其进一步技术方案为：所述根据所述IRP文件判断对文件的操作是否符合所述加解密策略，包括：

解析所述IRP文件，确定对文件的操作类型以及文件的类型；

根据对文件的操作类型以及文件的类型判断所述操作请求是否属于所述加解密策略中的需要加解密操作类型；

若所述操作请求属于所述加解密策略中的需要加解密操作类型，则确定对文件的操作是所述加解密策略中的需要加解密操作类型；

若所述操作请求不属于所述加解密策略中的需要加解密操作类型，则确定对文件的操作不是所述加解密策略中的需要加解密操作类型。

其进一步技术方案为：解密技术对所述文件进行加解密操作，以得到处理结果；

所述按照所述操作请求对应的需要加解密操作类型内的策略且利用U盾加解密技术对所述文件进行加解密操作，以得到处理结果，包括：

按照所述操作请求对应的需要加解密操作类型内的策略，且将加解密环节利用U盾加解密技术对所述文件进行加解密操作，以得到处理结果；

其中，利用U盾加解密技术对所述文件进行加解密操作，对于写文件加密的操作时，截获IRP_MJ_WRITE写文件的信息，将加密前的文件内容用PREAD_WRITE_COMPLETION_CONTEXT结构记录下来，当IRP文件接收完毕后，将加密前的文件内容重新赋值给IRP文件，并返回至IO管理器；对于读文件加密的操作时，截获IRP_MJ_READ读文件的信息，当读文件是加密文件，在完成函数SfReadCompletion中解密。

其进一步技术方案为：所述发送所述处理结果，包括：

获取所有终端的公钥证书；

将所有终端的公钥证书导入名片管理列表中；

从所述名片管理列表中选取需要进行密文通信的终端，并导入对应的公钥证书；

将所述处理结果发送至需要进行密文通信的终端，以由需要进行密文通信的终端根据U盾内的相关密钥进行解密。

其进一步技术方案为：所述发送所述处理结果，包括：

初始化U盾；

根据所述处理结果生成共享密文；

将所述共享密文在文件共享组内进行共享，以供文件共享组内的U盾对所述共享密文进行解密。

本发明还提供了基于U盾的文档加解密装置，包括：

文件获取单元，用于获取由IO管理器转换对文件的操作请求后形成的IRP文件；

命令获取单元，用于获取来自应用程序的控制命令；

反馈单元，用于根据所述控制命令反馈状态信息至应用程序，以由应用程序制定加解密策略，并由应用程序发送加解密策略；

接收单元，用于接收所述加解密策略；

判断单元，用于根据所述IRP文件判断对文件的操作是否是所述加解密策略中的需要加解密操作类型；

加解密单元，用于若对文件的操作是所述加解密策略中的需要加解密操作类型，则利用U盾加解密技术对所述文件进行加解密，以得到处理结果；

发送单元，用于发送所述处理结果。

本发明还提供了一种计算机设备，所述计算机设备包括存储器及处理器，所述存储器上存储有计算机程序，所述处理器执行所述计算机程序时实现上述的方法。

本发明还提供了一种存储介质，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述的方法。

本发明与现有技术相比的有益效果是：本发明通过获取IRP文件以及控制命令后，反馈状态信息至应用程序，接收加解密策略后，利用加解密策略确定文件是否需要进行加解密操作，对需要加解密操作的文件利用U盾加解密技术进行加解密，且可采用U盾传输和共享，实现提高基于U盾的文档加解密的安全性、可靠性、适用性以及合规性。

下面结合附图和具体实施例对本发明作进一步描述。

附图说明

为了更清楚地说明本发明实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的基于U盾的文档加解密方法的应用场景示意图；

图2为本发明实施例提供的基于U盾的文档加解密方法的流程示意图；

图3为本发明实施例提供的基于U盾的文档加解密方法的子流程示意图；

图4为本发明实施例提供的设备管理的示意图；

图5为本发明实施例提供的应用的逻辑结构示意图；

图6为本发明实施例提供的基于U盾的文档加解密装置的示意性框图；

图7为本发明实施例提供的基于U盾的文档加解密装置的判断单元的示意性框图；

图8为本发明实施例提供的计算机设备的示意性框图。

实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在此本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。如在本发明说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当进一步理解，在本发明说明书和所附权利要求书中使用的术语“和/ 或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

请参阅图1和图2，图1为本发明实施例提供的基于U盾的文档加解密方法的应用场景示意图。图2为本发明实施例提供的基于U盾的文档加解密方法的示意性流程图。该基于U盾的文档加解密方法应用于终端中。该终端与终端进行数据交互，终端上部署有应用程序，具体地，在终端中，软件安装后，电脑中原来的文件以及程序正常使用，没有任何影响；软件卸载后，密文依然还是密文，只有通过手动解密才能变成明文；软件运行时，不改变用户的电脑操作使用习惯，文件加解密都是在安全芯片里完成的，会话密钥不出硬件；物理存储介质上的密文，是经过加密算法生成的密文，对于用户就是乱码；U盾没有连接时，密文即不能被打开又不能被删除；拒绝恶意程序非法访问密文；拷贝密文，无论粘贴到哪里，新生成的文件还是密文；密文在网络上传递，或者作为附件存储在第三方文件服务器中，也还是密文；密文和非密文在正常操作情况下是通过图标上是否有锁头来区分；在同一台电脑上，U盾A生成的密文，其他U盾是无法正常操作；U盾在A电脑上生成的密文，只能在A电脑上正常操作，密文在其他电脑上即使有同一个U盾也是不能正常打开的；会话密钥明文不出U盾里的安全芯片，外面是无法获得会话密钥破解加密文件；

图2是本发明实施例提供的基于U盾的文档加解密方法的流程示意图。如图2所示，该方法包括以下步骤S110至S150。

S110、获取由IO管理器转换对文件的操作请求后形成的IRP文件。

在本实施例中，IRP文件是指根据对文件的操作请求进行转换形成内核驱动可以识别的文件。

具体地，当对文件进行操作时，终端调用通知IO管理器，IO管理器会将操作请求转化成内核驱动可以识别的IRP，并发往文件过滤驱动，当然终端上可能有多个文件过滤驱动。

S120、获取来自应用程序的控制命令。

在本实施例中，控制命令是指由应用程序操作形成的控制指令。

S130、根据所述控制命令反馈状态信息至应用程序，以由应用程序制定加解密策略，并由应用程序发送加解密策略。

在本实施例中，应用程序向终端的驱动程序发送控制命令。过滤驱动向应用程序返回状态信息；应用程序制定加解密策略，如授权需要加密的程序或者取消已经授权的程序。

具体地，所述加解密策略包括属于授权进程中打开非空非加密文件的操作，不进行加解密操作；属于授权进程中打开非空加密文件的操作，进行第一种加解密方式；属于授权进程打开空文件的操作，进行第二种加解密方式；属于非授权进程中打开非空非加密文件的操作，不进行加解密操作；属于非授权进程中打开非空加密文件的操作，进行第三种加解密方式；属于非授权进程中打开空文件的操作，不进行加解密操作。

其中，所述第一种加解密方式包括将所述文件标记为读写要加解密类型，并进行加解密操作，刷新缓存；所述第二种加解密方式包括将所述文件标记为读写要加解密类型，并进行加解密操作；所述第三种加解密方式包括将所述文件标记为读写要加解密类型，并进行加解密操作，清空缓存。

S140、接收所述加解密策略；

S150、根据所述IRP文件判断对文件的操作是否是所述加解密策略中的需要加解密操作类型。

在一实施例中，请参阅图3，上述的步骤S150可包括步骤S151~S154。

S151、解析所述IRP文件，确定对文件的操作类型以及文件的类型；

S152、根据对文件的操作类型以及文件的类型判断所述操作请求是否属于所述加解密策略中的需要加解密操作类型；

S153、若所述操作请求属于所述加解密策略中的需要加解密操作类型，则确定对文件的操作是所述加解密策略中的需要加解密操作类型；

S154、若所述操作请求不属于所述加解密策略中的需要加解密操作类型，则确定对文件的操作不是所述加解密策略中的需要加解密操作类型。

S160、若对文件的操作是所述加解密策略中的需要加解密操作类型，则利用U盾加解密技术对所述文件进行加解密，以得到处理结果。

在本实施例中，处理结果是指利用U盾加解密技术对所述文件进行加解密后形成的结果。

在本实施例中，按照所述操作请求对应的需要加解密操作类型内的策略且利用U盾加解密技术对所述文件进行加解密操作，以得到处理结果。

具体地，按照所述操作请求对应的需要加解密操作类型内的策略，且将加解密环节利用U盾加解密技术对所述文件进行加解密操作，以得到处理结果；

其中，利用U盾加解密技术对所述文件进行加解密操作，对于写文件加密的操作时，截获IRP_MJ_WRITE写文件的信息，将加密前的文件内容用PREAD_WRITE_COMPLETION_CONTEXT结构记录下来，当IRP文件接收完毕后，将加密前的文件内容重新赋值给IRP文件，并返回至IO管理器；对于读文件加密的操作时，截获IRP_MJ_READ读文件的信息，当读文件是加密文件，在完成函数SfReadCompletion中解密。

具体地，前期绑定，创建设备，然后将创建的设备绑定到文件系统控制设备上，注册IRP_MJ_FILE_SYSTEM_CONTROL的派遣函数，这样在卷动态生成的时候就能生成设备并绑定它，在卷动态拔出时就能解除绑定。

打开文件，截获IRP_MJ_CREATE文件打开的消息，通过判断目前正在打开的文件是否符合我们的加解密策略，如果是，则记录下来保存在自定义的结构体中，对于同一个fcb的文件对象保持在_FILE_CONTEXT结构中，其结构设计如下：

typedef struct _FILE_CONTEXT

{

FILE_CONTEXT_HDR；

BOOLEAN DecryptOnRead; //读文件时解码

BOOLEAN EncryptOnWrite; //写文件时编码

BOOLEAN EncryptFlagExist; //编码标记已存在

BOOLEAN NeedEncrypt; //是个需要加密的文件

BOOLEAN EmptyFile; //是个空文件，需要在修改文件时写入加密头

ULONG EncryptContent;

BOOLEAN Destroying; //正在退出

KEVENT Event; //用于同步，序列化操作

ULONG state; //用于表示状态

LARGE_INTEGER FileValidLength; //文件有效长度，解决U盾读写问题

LIST_ENTRY FileObjectListEntry; //该文件的FileObject列表

KSPIN_LOCK FileObjectListEntryLock;

ULONG AesLevel; //密钥级别

UCHAR szCipherAESKey[32]; //密钥串

WCHAR Name[MAX_PATH];

} FILE_CONTEXT, *PFILE_CONTEXT;

写文件，截获IRP_MJ_WRITE写文件的信息，先将加密前的文件内容用PREAD_WRITE_COMPLETION_CONTEXT结构记录下来，等待下发IRP完成时IRP返回时将加密前的内容重新赋值给IRP，然后返回给上层驱动。这样写进磁盘（物理介质）的数据就是加密了的。

读文件，截获IRP_MJ_READ读文件的信息，如果是加密文件，在完成函数SfReadCompletion函数中解密（要等确定读出数据后才解密）。

关闭文件，截获IRP_MJ_CLOSE关闭文件的信息，在文件彻底关闭(所有句柄都关闭)时，给需要加密的文件加上K的加密头ZZXX。

加上标记头的时机，在文件所有句柄都关掉的时候加上的。也就是在关闭文件函数里面加上的。

对于U盾加解密技术而言，其管理功能由设备管理、访问控制、文件管理、应用管理、容器管理、密码服务这六部分组成，设备管理是指一个设备中存在设备认证密钥和多个应用，应用之间相互独立，如图4所示，访问控制：访问控制主要完成设备认证、PIN码管理和安全状态管理等操作。文件管理函数用以满足用户扩展开发的需要，包括创建文件、删除文件、枚举文件、获取文件信息、文件读写等操作。应用管理主要完成应用的创建、枚举、删除、打开、关闭等操作对应的应用里面包含各自的容器、文件、PIN码，如图5所示，容器管理用于满足各种不同容器的管理，包括创建、删除、枚举、打开和关闭容器的操作。容器中存放保护密钥、加密密钥、签名密钥对。其中保护密钥用于对密钥加密保护，加密密钥用于保护加密密钥，签名密钥对用于数字签名和验证。其中，签名密钥对由内部产生，加密密钥由内部产生。0密码服务：密码服务函数提供对称算法运算、非对称算法运算、密码杂凑运算、密钥管理、消息鉴别码计算等功能。

S170、发送所述处理结果。

在一实施例中，该步骤可包括：

获取所有终端的公钥证书；将所有终端的公钥证书导入名片管理列表中；从所述名片管理列表中选取需要进行密文通信的终端，并导入对应的公钥证书；将所述处理结果发送至需要进行密文通信的终端，以由需要进行密文通信的终端根据U盾内的相关密钥进行解密。

在本实施例中，所述公钥证书是通过终端连接U盾，以初次绑定加密软件时生成的通信密钥证书。

终端在初次安全装时，U盾将与加密软件绑定再与主机硬件绑定，这时将生成用于密文通信的公钥证书。

公钥证书的内容包括本人规定要信息以及本人基本信息如姓名和单位等。

每个U盘的私钥都是通过安全芯片随机函数发生器生成的符合设定要求的一组密码，保证每个U盾的私钥都不会重复，私钥在整个生命周期里，都不会出硬件加密芯片，发布出去的公钥只能做为加密功能使用。

只有当公钥证书发送成功后才会执行密文通信流程，否则执行结束步骤。

在本实施例中，名片管理列表中集合了所有可进行密文通信的终端的公钥证书。

在一实施例中，从所述名片管理列表中选取需要进行密文通信的终端，并导入对应的公钥证书可包括：

从所述名片管理列表中选取需要进行密文通信的终端，并确定对应的公钥证书；

判断所述公钥证书是否合法；

若所述公钥证书合法，则选择所述公钥证书，并导入所述公钥证书中的公钥到U盾内；

若所述公钥证书不合法，则执行所述从所述名片管理列表中选取需要进行密文通信的终端，并确定对应的公钥证书。

只有在公钥证书合法且导入成功之后才会进入密文通信流程，采用对方发送公钥证书的方式进行匹配传递，公钥证书采用一次导入，多次使用的方式。

设置便于操作管理的公钥指向性信息如某人、某单位或某部门、昵称等，并导入公钥证书，该证书用在与你密文通信的人进行通信文件加密使用，产品生成证书及比对证书所用的公钥和私钥是由安全芯片随机函数发生器产生的随机数，并由芯片内置SM2国密算法运算产生，保证每个U盾的公钥私钥的唯一性。

处理结果可以是根据随机产生一文一密的种子密钥对需要发送的文件进行加密所形成的文件。

具体地，随机产生一文一密的种子密钥。

在本实施例中，种子密钥是指后续可用于按照预定的规则运算形成用于加密文件的密钥的基础内容。

利用所述种子密钥通过U盾对需要发送的文件进行加密，以得到密文。

当用户选择启动密文通信时，软件会先生成种子密钥，再根据种子密钥生成会话密钥；通过U盾的安全芯片里的随机发生器生成一文一密的种子密钥，在通过预定的规则运算生成会话密钥；U盾安全芯片会根据会话密钥对文件进行加密，加密整个过程会话密钥都不出U盾安全芯片，且用完即作废。会话密钥的种子密钥是通过SM2的公钥进行非对称加密，并将加密过的种子密钥导出U盾。

在本实施例中，通过导入公钥加密种子的密钥产生加密的种子密钥，将加密的种子密钥导出U盾，并利用加密的种子密钥利用U盾对需要发送的文件进行加密，以得到密文。

具体地，通过U盾内设定的方案结合所述种子密钥生成会话密钥；通过所述会话密钥利用U盾对需要发送的文件进行加密，以得到密文。

在加密之后，需要先对密文进行判断是否加密成功，只有加密成功的密文才会被发送至终端。

U盾的私钥在生成到生命周期结束都不会出U盾的安全芯片。加密过的种子密钥解密过程，全部在U盾的安全芯片中进行，整个过程不出U盾安全芯片。

在本实施例中，解密的会话密钥是由产成的种子密钥，经过U盾的内部的运算机制取得的，整个过程密钥明文不出U盾安全芯片。文件内容的解密过程，全部在U盾安全芯片内部完成，整个解密过程不出U盾安全芯片。所有密钥和加解密运算及管理都在安全芯片里完成，密钥明文是不会出硬件的，保证了产品的安全性和可靠性以及合规合法。

具体地，将所述密文发送至需要进行密文通信的终端，以由需要进行密文通信的终端判断所述密文是否是密文通信生成的文件，当所述密文是密文通信生成的文件，从与需要进行密文通信的终端的U盾中读取公钥信息、种子密钥、密文通信标志，并所述密文使用的公钥证书是本终端的公钥证书时，通过U盾内部的私钥解密被加密的种子密钥，通过解密后的种子密钥生成会话密钥，并利用会话密钥解密所述密文。

需要进行密文通信的终端通过U盾读取加密文件的公钥信息以及文件通信标识与本机比对，U盾里有本机的通信信息及公钥对应的私钥。

会话密钥明文不出U盾里的安全芯片，外面是无法获得会话密钥破解加密文件的；支持密文通信，密文通信只能在特定人之间进行，就是发给谁的密文，只能他在指定的电脑和指定的U盾联机情况下才能解密，任何人即使获得该密文也无法打开；

通过利用终端生成的公钥证书进行匹配传递密文，且采用一文一密的方式对需要发送的文件进行加密，加密的内容在U盾内执行，整个加密证书信息属于需要进行密文通信的终端才可以对密文进行解密，解密的内容也在U盾内执行，实现在指定的情况下，才可以解密，安全性高，只要证书是本机的，便可进行密文读取，可做到无障碍读取密文。

在另一实施例中，发送所述处理结果的步骤可包括：

初始化U盾；根据所述处理结果生成共享密文；将所述共享密文在文件共享组内进行共享，以供文件共享组内的U盾对所述共享密文进行解密。

具体地，U盾初始化：在U盾中创建一个用于实现共享文件的应用app_share。设置U盾加入一个共享文件组的操作流程：在app_share应用中生成一个容器container_group1。在container_group1容器中导入一对种子密钥，该密钥对是用于组group1所有共享加密文件的密钥生成的种子密钥。

共享密文的生成：随机生成一个特征码1，使用容器中种子密钥的公钥对这个特征码进行加密，把生成的密文（特征码2）记录在密文头结构中。使用种子密钥的私钥解密特征码2，并生成会话密钥（这个会话密钥就是该文件加解密的密钥，全程对外未知）。使用会话密钥对文件内容进行加解密。

共享密文的解密：读取密文头结构中的特征码2，以及容器名称。使用容器中种子密钥的私钥对特征码2进行解密，并生成会话密钥。使用会话密钥对密文进行解密。

在U盾中，既有用于个人文件加解密的密钥，又有用于多人共享密文的密钥，而这些密钥是保存在不同的区域，功能也各不相同。

所有的种子密钥的分发和管理是通过专用初始化管理工具，种子密钥的保存和管理工具的使用必须经过安全措施。

S180、若对文件的操作不是所述加解密策略中的需要加解密操作类型，则发送所述文件至磁盘或者其他过滤驱动。

在采用U盾进行加解密时涉及到会话密钥生成过程，具体包括遍历U盾设备，连接第一个U盾设备，U盾设备用户PIN认证，打开U盾设备应用XinXinSingleAppSM1，打开U盾XinXinSingleContainer；导出容器中加密密钥对的公密钥，该环节使用U盾容器的加密密钥对的公钥，对会话密钥做加密运算并输出结果，加密过程在U盾中完成；结合电脑设备硬件信息特征码，经杂凑算法，计算结果作为该电脑会话密钥密文文件名，读取文件信息，读取失败，则创建session文件，生成会话密钥，并导出会话密钥密文，将会话密钥密文写入session文件，读取会话密钥密文文件，导入会话密钥密文到设备容器，该环节使用U盾容器的加密密钥对，对会话密钥密文内容进行解密，并生成会话密钥，该过程在U盾中完成，生成会话密钥句柄。读取成功则执行读取会话密钥密文文件。

整个初始化过程为：SerialNumbercheck，取出eflash上存储的序列号，判断与初始序列号匹配是否成功，当匹配成功，获取序列号并写入eflash，判断sm4加密密钥是否为空，当为空，则调用get_hrng()生成16位随机数，存到eflash加解密密钥位置，赋值到private_pbkey()，调用Protected_SM2_Keygen()生成SM2公私钥存到eflash，将数据写到eflash中并更新自检数据，当匹配失败，则将eflsh中的加解密密钥取出赋值到private_pbkey()中，当密钥不为空，则执行将数据写到eflash中并更新自检数据。其中，生成的private_pbKey为真随机数，主要用来对eflash上的数据存储时进行加密，使用时进行解密，为一盘一密。所有密钥都是用该密钥进行加密后再存入eflash。SM2公私钥对主要用来进行SM2加解密。

在本实施例中，U盾的应用软件执行过程为：应用程序启动，判断Ukey是否存在SFK_Enum，若是，连接设备SKF_ConnectDev；打开应用XXSKF_OpenApplication；打开容器XXSKF_OpenContainer；校验PinXXSKF_VerifyPin；导出秘钥XXSKF_ExportPublicKey；杂凑初始化XXSKF_DigestInit；单组数据杂凑XXSKF_Digest；获取解密密码XXSKF_GetUesrDecrypCipher；导入加密句柄XXSKF_ImportSessionKey；初始化秘钥接口XXSKF_EncryptInit；初始化秘钥接口XXSKF_DecryptInit；打开外发容器XXSKF_OpenContainer；获取外发秘钥XXSKF_GetEncrypCipher；初始化外发秘钥接口XXSKF_EncryptInit；获取设备序列号XXSKF_GetSerialNumber，并设置上线标记；若否，设置下线标记。

启动定时线程5s，判断Ukey是否存在SFK_Enum；若是，获取Ukey的状态SKF_GetDevState；分析Ukey在线状态上位机，若下线到上线变化，执行判断Ukey是否存在SFK_Enum；当不变或上线到下线变化，则执行启动定时线程5s。原子锁的工作过程：启动加密流程，读取文件2进制，切割文件内容最大4096最小16，加密内容SKF_Encript。

本实施例的方法解决终端文档加密软件的安全性与合规性问题，商用密码检测中心有个不成文的规矩就是密钥不能除硬件。也增加了产品的易用性和对工作环境的适应性，保障了加密文件存储、传输中的各个环节的安全性、可靠性和唯一性。软件安装后，电脑中原来的文件，以及程序正常使用，没有任何影响；软件卸载后，密文依然还是密文，只有通过手动解密才能变成明文；软件运行时，不改变用户的电脑操作使用习惯，文件加解密都是在安全芯片里完成的，会话密钥不出硬件；物理存储介质上的密文，是经过加密算法生成的密文，对于用户就是乱码；U盾没有连接时，密文即不能被打开又不能被删除；拒绝恶意程序非法访问密文；拷贝密文，无论粘贴到哪里，新生成的文件还是密文；密文在网络上传递，或者作为附件存储在第三方文件服务器中，也还是密文；密文和非密文，在正常操作情况下是通过图标上是否有锁头来区分；在同一台电脑上，U盾A生成的密文，其他U盾是无法正常操作；U盾在A电脑上生成的密文，只能在A电脑上正常操作，密文在其他电脑上即使有同一个U盾也是不能正常打开的；会话密钥明文不出U盾里的安全芯片，外面是无法获得会话密钥破解加密文件的；支持密文通信，密文通信只能在特定人之间进行，就是发给谁的密文，只能他在指定的电脑和指定的U盾联机情况下才能解密，任何人即使获得该密文也无法打开；支持密文共享功能，支持在特定的人群之间密文无障碍交流，其他人即使获得密文也无法正常读取。

本实施例的方法采用符合设定密码标准和具备商用密码产品生产资质厂商提供的芯片作为密码部件，该加密U盾内置密码部件，具有批准的密码算法，密钥的存储、运算和通讯符合安全要求，从而确保产品本身的安全性；研制了文件过滤驱动，该驱动提供了和应用程序校验的认证方式，防止黑客程序非法操作驱动，进一步保证了系统的安全性。同时在产品开发与制作过程中，也充分考虑了环境和管理的安全性，

采用稳定可靠的成熟技术，保证系统长期安全运行，系统中的软、硬件及信息资源能满足可靠性设计要求。遵循有关信息安全标准，具有必要的安全保护和保密措施，以及对计算机犯罪的防范能力，确保信息安全，提高系统的抗干扰能力。

U盾采用新型的USB接口，使得该产品不需要读卡器之类的接口设备就可以直接与计算机相连，并且芯信卫士加密软件能自动识别机器上的加密U盾，只要正确的加密U盾接入，加密软件就能启动，操作相当简捷。

能运行在银河麒麟操作系统以后，具有多操作系统的适用性原则；加密文件跟文件格式无关，任意文件均可以加密；提供多种外部接口函数，适用于各种需要加解密处理的应用系统之中；能对文件实现透明加解密，不改变用户原有的操作习惯，对用户来说，加解密操作是完全透明的；能有效阻止黑客和间谍软件非法截取数据。

驱动模块与应用之间的交互采用标准化的调用接口，可以防止其他间谍软件的非法调用；提供标准的外部调用接口，用于提供二次开发接口。

上述的基于U盾的文档加解密方法，通过获取IRP文件以及控制命令后，反馈状态信息至应用程序，接收加解密策略后，利用加解密策略确定文件是否需要进行加解密操作，对需要加解密操作的文件利用U盾加解密技术进行加解密，且可采用U盾传输和共享，实现提高基于U盾的文档加解密的安全性、可靠性、适用性以及合规性。

图6是本发明实施例提供的一种基于U盾的文档加解密装置300的示意性框图。如图6所示，对应于以上基于U盾的文档加解密方法，本发明还提供一种基于U盾的文档加解密装置300。该基于U盾的文档加解密装置300包括用于执行上述基于U盾的文档加解密方法的单元，该装置可以被配置于终端中。具体地，请参阅图6，该基于U盾的文档加解密装置300包括文件获取单元301、命令获取单元302、反馈单元303、接收单元304、判断单元305、加解密单元306以及发送单元307。

文件获取单元301，用于获取由IO管理器转换对文件的操作请求后形成的IRP文件；命令获取单元302，用于获取来自应用程序的控制命令；反馈单元303，用于根据所述控制命令反馈状态信息至应用程序，以由应用程序制定加解密策略，并由应用程序发送加解密策略；接收单元304，用于接收所述加解密策略；判断单元305，用于根据所述IRP文件判断对文件的操作是否是所述加解密策略中的需要加解密操作类型；加解密单元306，用于若对文件的操作是所述加解密策略中的需要加解密操作类型，则利用U盾加解密技术对所述文件进行加解密，以得到处理结果；发送单元307，用于发送所述处理结果。。

在一实施例中，如图7所示，所述判断单元305包括解析子单元3051、判断子单元3052、第一确定子单元3053以及第二确定子单元3054。

解析子单元3051，用于解析所述IRP文件，确定对文件的操作类型以及文件的类型；判断子单元3052，用于根据对文件的操作类型以及文件的类型判断所述操作请求是否属于所述加解密策略中的需要加解密操作类型；第一确定子单元3053，用于若所述操作请求属于所述加解密策略中的需要加解密操作类型，则确定对文件的操作是所述加解密策略中的需要加解密操作类型；第二确定子单元3054，用于若所述操作请求不属于所述加解密策略中的需要加解密操作类型，则确定对文件的操作不是所述加解密策略中的需要加解密操作类型。

在一实施例中，所述加解密单元306，用于按照所述操作请求对应的需要加解密操作类型内的策略且利用U盾加解密技术对所述文件进行加解密操作，以得到处理结果。

在一实施例中，所述加解密单元306，用于按照所述操作请求对应的需要加解密操作类型内的策略，且将加解密环节利用U盾加解密技术对所述文件进行加解密操作，以得到处理结果；

其中，利用U盾加解密技术对所述文件进行加解密操作，对于写文件加密的操作时，截获IRP_MJ_WRITE写文件的信息，将加密前的文件内容用PREAD_WRITE_COMPLETION_CONTEXT结构记录下来，当IRP文件接收完毕后，将加密前的文件内容重新赋值给IRP文件，并返回至IO管理器；对于读文件加密的操作时，截获IRP_MJ_READ读文件的信息，当读文件是加密文件，在完成函数SfReadCompletion中解密。

在一实施例中，所述发送单元包括：

证书获取子单元，用于获取所有终端的公钥证书；导入子单元，用于将所有终端的公钥证书导入名片管理列表中；选取子单元，用于从所述名片管理列表中选取需要进行密文通信的终端，并导入对应的公钥证书；结果发送子单元，用于将所述处理结果发送至需要进行密文通信的终端，以由需要进行密文通信的终端根据U盾内的相关密钥进行解密。

在一实施例中，所述发送单元包括：

初始化子单元，用于初始化U盾；共享密文子单元，用于根据所述处理结果生成共享密文；共享子单元，用于将所述共享密文在文件共享组内进行共享，以供文件共享组内的U盾对所述共享密文进行解密。

需要说明的是，所属领域的技术人员可以清楚地了解到，上述基于U盾的文档加解密装置300和各单元的具体实现过程，可以参考前述方法实施例中的相应描述，为了描述的方便和简洁，在此不再赘述。

上述基于U盾的文档加解密装置300可以实现为一种计算机程序的形式，该计算机程序可以在如图8所示的计算机设备上运行。

请参阅图8，图8是本申请实施例提供的一种计算机设备的示意性框图。该计算机设备500可以是终端也是服务器。

参阅图8，该计算机设备500包括通过系统总线501连接的处理器502、存储器和网络接口505，其中，存储器可以包括非易失性存储介质503和内存储器504。

该非易失性存储介质503可存储操作系统5031和计算机程序5032。该计算机程序5032包括程序指令，该程序指令被执行时，可使得处理器502执行一种基于U盾的文档加解密方法。

该处理器502用于提供计算和控制能力，以支撑整个计算机设备500的运行。

该内存储器504为非易失性存储介质503中的计算机程序5032的运行提供环境，该计算机程序5032被处理器502执行时，可使得处理器502执行一种基于U盾的文档加解密方法。

该网络接口505用于与其它设备进行网络通信。本领域技术人员可以理解，图8中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备500的限定，具体的计算机设备500可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

其中，所述处理器502用于运行存储在存储器中的计算机程序5032，以实现如下步骤：

获取由IO管理器转换对文件的操作请求后形成的IRP文件；获取来自应用程序的控制命令；根据所述控制命令反馈状态信息至应用程序，以由应用程序制定加解密策略，并由应用程序发送加解密策略；接收所述加解密策略；根据所述IRP文件判断对文件的操作是否是所述加解密策略中的需要加解密操作类型；若对文件的操作是所述加解密策略中的需要加解密操作类型，则利用U盾加解密技术对所述文件进行加解密，以得到处理结果；发送所述处理结果。

其中，所述加解密策略包括属于授权进程中打开非空非加密文件的操作，不进行加解密操作；属于授权进程中打开非空加密文件的操作，进行第一种加解密方式；属于授权进程打开空文件的操作，进行第二种加解密方式；属于非授权进程中打开非空非加密文件的操作，不进行加解密操作；属于非授权进程中打开非空加密文件的操作，进行第三种加解密方式；属于非授权进程中打开空文件的操作，不进行加解密操作。

所述第一种加解密方式包括将所述文件标记为读写要加解密类型，并进行加解密操作，刷新缓存；所述第二种加解密方式包括将所述文件标记为读写要加解密类型，并进行加解密操作；所述第三种加解密方式包括将所述文件标记为读写要加解密类型，并进行加解密操作，清空缓存。

在一实施例中，处理器502在实现所述根据所述IRP文件判断对文件的操作是否符合所述加解密策略步骤时，具体实现如下步骤：

解析所述IRP文件，确定对文件的操作类型以及文件的类型；根据对文件的操作类型以及文件的类型判断所述操作请求是否属于所述加解密策略中的需要加解密操作类型；若所述操作请求属于所述加解密策略中的需要加解密操作类型，则确定对文件的操作是所述加解密策略中的需要加解密操作类型；若所述操作请求不属于所述加解密策略中的需要加解密操作类型，则确定对文件的操作不是所述加解密策略中的需要加解密操作类型。

在一实施例中，处理器502在实现所述利用U盾加解密技术对所述文件进行加解密，以得到处理结果步骤时，具体实现如下步骤：

按照所述操作请求对应的需要加解密操作类型内的策略且利用U盾加解密技术对所述文件进行加解密操作，以得到处理结果。

在一实施例中，处理器502在实现所述按照所述操作请求对应的需要加解密操作类型内的策略且利用U盾加解密技术对所述文件进行加解密操作，以得到处理结果步骤时，具体实现如下步骤：

按照所述操作请求对应的需要加解密操作类型内的策略，且将加解密环节利用U盾加解密技术对所述文件进行加解密操作，以得到处理结果；

其中，利用U盾加解密技术对所述文件进行加解密操作，对于写文件加密的操作时，截获IRP_MJ_WRITE写文件的信息，将加密前的文件内容用PREAD_WRITE_COMPLETION_CONTEXT结构记录下来，当IRP文件接收完毕后，将加密前的文件内容重新赋值给IRP文件，并返回至IO管理器；对于读文件加密的操作时，截获IRP_MJ_READ读文件的信息，当读文件是加密文件，在完成函数SfReadCompletion中解密。

在一实施例中，处理器502在实现所述发送所述处理结果步骤时，具体实现如下步骤：

获取所有终端的公钥证书；将所有终端的公钥证书导入名片管理列表中；从所述名片管理列表中选取需要进行密文通信的终端，并导入对应的公钥证书；将所述处理结果发送至需要进行密文通信的终端，以由需要进行密文通信的终端根据U盾内的相关密钥进行解密。

在一实施例中，处理器502在实现所述发送所述处理结果步骤时，具体实现如下步骤：

初始化U盾；根据所述处理结果生成共享密文；将所述共享密文在文件共享组内进行共享，以供文件共享组内的U盾对所述共享密文进行解密。

应当理解，在本申请实施例中，处理器502可以是中央处理单元 (CentralProcessing Unit，CPU)，该处理器502还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路 (Application Specific IntegratedCircuit，ASIC)、现成可编程门阵列 (Field-Programmable Gate Array，FPGA) 或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。其中，通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本领域普通技术人员可以理解的是实现上述实施例的方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成。该计算机程序包括程序指令，计算机程序可存储于一存储介质中，该存储介质为计算机可读存储介质。该程序指令被该计算机系统中的至少一个处理器执行，以实现上述方法的实施例的流程步骤。

因此，本发明还提供一种存储介质。该存储介质可以为计算机可读存储介质。该存储介质存储有计算机程序，其中该计算机程序被处理器执行时使处理器执行如下步骤：

获取由IO管理器转换对文件的操作请求后形成的IRP文件；获取来自应用程序的控制命令；根据所述控制命令反馈状态信息至应用程序，以由应用程序制定加解密策略，并由应用程序发送加解密策略；接收所述加解密策略；根据所述IRP文件判断对文件的操作是否是所述加解密策略中的需要加解密操作类型；若对文件的操作是所述加解密策略中的需要加解密操作类型，则利用U盾加解密技术对所述文件进行加解密，以得到处理结果；发送所述处理结果。

其中，所述加解密策略包括属于授权进程中打开非空非加密文件的操作，不进行加解密操作；属于授权进程中打开非空加密文件的操作，进行第一种加解密方式；属于授权进程打开空文件的操作，进行第二种加解密方式；属于非授权进程中打开非空非加密文件的操作，不进行加解密操作；属于非授权进程中打开非空加密文件的操作，进行第三种加解密方式；属于非授权进程中打开空文件的操作，不进行加解密操作。

所述第一种加解密方式包括将所述文件标记为读写要加解密类型，并进行加解密操作，刷新缓存；所述第二种加解密方式包括将所述文件标记为读写要加解密类型，并进行加解密操作；所述第三种加解密方式包括将所述文件标记为读写要加解密类型，并进行加解密操作，清空缓存。

在一实施例中，所述处理器在执行所述计算机程序而实现所述根据所述IRP文件判断对文件的操作是否符合所述加解密策略步骤时，具体实现如下步骤：

解析所述IRP文件，确定对文件的操作类型以及文件的类型；根据对文件的操作类型以及文件的类型判断所述操作请求是否属于所述加解密策略中的需要加解密操作类型；若所述操作请求属于所述加解密策略中的需要加解密操作类型，则确定对文件的操作是所述加解密策略中的需要加解密操作类型；若所述操作请求不属于所述加解密策略中的需要加解密操作类型，则确定对文件的操作不是所述加解密策略中的需要加解密操作类型。

在一实施例中，所述处理器在执行所述计算机程序而实现所述利用U盾加解密技术对所述文件进行加解密，以得到处理结果步骤时，具体实现如下步骤：

按照所述操作请求对应的需要加解密操作类型内的策略且利用U盾加解密技术对所述文件进行加解密操作，以得到处理结果。

在一实施例中，所述处理器在执行所述计算机程序而实现所述按照所述操作请求对应的需要加解密操作类型内的策略且利用U盾加解密技术对所述文件进行加解密操作，以得到处理结果步骤时，具体实现如下步骤：

按照所述操作请求对应的需要加解密操作类型内的策略，且将加解密环节利用U盾加解密技术对所述文件进行加解密操作，以得到处理结果；

其中，利用U盾加解密技术对所述文件进行加解密操作，对于写文件加密的操作时，截获IRP_MJ_WRITE写文件的信息，将加密前的文件内容用PREAD_WRITE_COMPLETION_CONTEXT结构记录下来，当IRP文件接收完毕后，将加密前的文件内容重新赋值给IRP文件，并返回至IO管理器；对于读文件加密的操作时，截获IRP_MJ_READ读文件的信息，当读文件是加密文件，在完成函数SfReadCompletion中解密。

在一实施例中，所述处理器在执行所述发送所述处理结果步骤时，具体实现如下步骤：

获取所有终端的公钥证书；将所有终端的公钥证书导入名片管理列表中；从所述名片管理列表中选取需要进行密文通信的终端，并导入对应的公钥证书；将所述处理结果发送至需要进行密文通信的终端，以由需要进行密文通信的终端根据U盾内的相关密钥进行解密。

在一实施例中，所述处理器在执行所述计算机程序而实现所述发送所述处理结果步骤时，具体实现如下步骤：

初始化U盾；根据所述处理结果生成共享密文；将所述共享密文在文件共享组内进行共享，以供文件共享组内的U盾对所述共享密文进行解密。

所述存储介质可以是U盘、移动硬盘、只读存储器（Read-Only Memory，ROM）、磁碟或者光盘等各种可以存储程序代码的计算机可读存储介质。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的。例如，各个单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。

本发明实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。本发明实施例装置中的单元可以根据实际需要进行合并、划分和删减。另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。

该集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，终端，或者网络设备等）执行本发明各个实施例所述方法的全部或部分步骤。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (10)

1.基于U盾的文档加解密方法，其特征在于，包括：

获取由IO管理器转换对文件的操作请求后形成的IRP文件；

获取来自应用程序的控制命令；

根据所述控制命令反馈状态信息至应用程序，以由应用程序制定加解密策略，并由应用程序发送加解密策略；

接收所述加解密策略；

根据所述IRP文件判断对文件的操作是否是所述加解密策略中的需要加解密操作类型；

若对文件的操作是所述加解密策略中的需要加解密操作类型，则利用U盾加解密技术对所述文件进行加解密，以得到处理结果；

发送所述处理结果。

2.根据权利要求1所述的基于U盾的文档加解密方法，其特征在于，所述加解密策略包括属于授权进程中打开非空非加密文件的操作，不进行加解密操作；属于授权进程中打开非空加密文件的操作，进行第一种加解密方式；属于授权进程打开空文件的操作，进行第二种加解密方式；属于非授权进程中打开非空非加密文件的操作，不进行加解密操作；属于非授权进程中打开非空加密文件的操作，进行第三种加解密方式；属于非授权进程中打开空文件的操作，不进行加解密操作。

3.根据权利要求2所述的基于U盾的文档加解密方法，其特征在于，所述第一种加解密方式包括将所述文件标记为读写要加解密类型，并进行加解密操作，刷新缓存；所述第二种加解密方式包括将所述文件标记为读写要加解密类型，并进行加解密操作；所述第三种加解密方式包括将所述文件标记为读写要加解密类型，并进行加解密操作，清空缓存。

4.根据权利要求3所述的基于U盾的文档加解密方法，其特征在于，所述根据所述IRP文件判断对文件的操作是否符合所述加解密策略，包括：

解析所述IRP文件，确定对文件的操作类型以及文件的类型；

根据对文件的操作类型以及文件的类型判断所述操作请求是否属于所述加解密策略中的需要加解密操作类型；

若所述操作请求属于所述加解密策略中的需要加解密操作类型，则确定对文件的操作是所述加解密策略中的需要加解密操作类型；

若所述操作请求不属于所述加解密策略中的需要加解密操作类型，则确定对文件的操作不是所述加解密策略中的需要加解密操作类型。

5.根据权利要求4所述的基于U盾的文档加解密方法，其特征在于，所述利用U盾加解密技术对所述文件进行加解密，以得到处理结果，包括：

按照所述操作请求对应的需要加解密操作类型内的策略且利用U盾加解密技术对所述文件进行加解密操作，以得到处理结果；

所述按照所述操作请求对应的需要加解密操作类型内的策略且利用U盾加解密技术对所述文件进行加解密操作，以得到处理结果，包括：

按照所述操作请求对应的需要加解密操作类型内的策略，且将加解密环节利用U盾加解密技术对所述文件进行加解密操作，以得到处理结果；

其中，利用U盾加解密技术对所述文件进行加解密操作，对于写文件加密的操作时，截获IRP_MJ_WRITE写文件的信息，将加密前的文件内容用PREAD_WRITE_COMPLETION_CONTEXT结构记录下来，当IRP文件接收完毕后，将加密前的文件内容重新赋值给IRP文件，并返回至IO管理器；对于读文件加密的操作时，截获IRP_MJ_READ读文件的信息，当读文件是加密文件，在完成函数SfReadCompletion中解密。

6.根据权利要求1所述的基于U盾的文档加解密方法，其特征在于，所述发送所述处理结果，包括：

获取所有终端的公钥证书；

将所有终端的公钥证书导入名片管理列表中；

从所述名片管理列表中选取需要进行密文通信的终端，并导入对应的公钥证书；

将所述处理结果发送至需要进行密文通信的终端，以由需要进行密文通信的终端根据U盾内的相关密钥进行解密。

7.根据权利要求1所述的基于U盾的文档加解密方法，其特征在于，所述发送所述处理结果，包括：

初始化U盾；

根据所述处理结果生成共享密文；

将所述共享密文在文件共享组内进行共享，以供文件共享组内的U盾对所述共享密文进行解密。

8.基于U盾的文档加解密装置，其特征在于，包括：

文件获取单元，用于获取由IO管理器转换对文件的操作请求后形成的IRP文件；

命令获取单元，用于获取来自应用程序的控制命令；

反馈单元，用于根据所述控制命令反馈状态信息至应用程序，以由应用程序制定加解密策略，并由应用程序发送加解密策略；

接收单元，用于接收所述加解密策略；

判断单元，用于根据所述IRP文件判断对文件的操作是否是所述加解密策略中的需要加解密操作类型；

加解密单元，用于若对文件的操作是所述加解密策略中的需要加解密操作类型，则利用U盾加解密技术对所述文件进行加解密，以得到处理结果；

发送单元，用于发送所述处理结果。

9.一种计算机设备，其特征在于，所述计算机设备包括存储器及处理器，所述存储器上存储有计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至7中任一项所述的方法。

10.一种存储介质，其特征在于，所述存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的方法。