# QSL卡片的数字签名 1. 前言近年来, 越来越多的电台不再发送纸质QSL卡片, 转而使用电子版QSL卡片或使用在线日志服务.我们意识到在线日志服务过于依赖某些中心化网站, 且不足以展示电台个性, 因而无法完全取代纸质QSL卡片. 同时, 不含有签名电子版QSL卡片极易被伪造, 不能独自有效证明通联的真实性. 本文提出了一种可行的数字签名方案, 在不影响电子QSL卡片功能、个性化QSL卡片的前提下, 对QSL卡片上的信息进行数字签名. 2. 范围本文定义了一种对数字QSL卡片进行数字签名的方法. 但本文不对公钥的分发、信任和吊销流程做出要求. 3. 要求本文提出的数字签名满足以下要求： i. 数字签名可以被方便的识别、验证且不依赖中心化第三方服务. ii. 数字签名不对QSL卡片设计、美观性产生显著影响 iii. 接收方对收到的QSL卡片进行格式转换等操作不影响签名有效性 iv. 接收方可以打印含有数字签名的QSL卡片, 打印后的卡片可以被独立验证. 4. 规范性引用文件 GB/T 1.1-2020 标准化工作导则第1部分：标准化文件的结构和起草规则. 本文中粗体“**（不）应**”、“**（不）宜**”、“**可**、**不必**”、“**（不）能**”、“**（不）可能**”的使用符合《GB/T 1.1-2020 标准化工作导则第1部分：标准化文件的结构和起草规则》中附录C的定义. 5. 定义 5.1 基本定义 - **字节** 由8位二进制组成的符号 - **签名有效载荷** 实际被签名的数据中, 有意义的部分 - **被签名数据** 数字签名算法的输入 - **签名** 由文件头、签名算法描述和数字签名等部分组成的文件 5.2 SSH消息本文多次描述SSH消息结构体, 在本文的语义下, 用到的类型有: - `ssh-string` 四个字节、大端序表示的字符串长度和由前述长度指定的字节串, 串中可以有Unicode NUL字符, 串位不含有多余的Unicode NUL字符. - `uint32` 四个字节、大端序表示的32位无符号整数. - `byte[N]` N个字节, 无其它信息 - `varint` 变长数字，其最高位表示是否为该数最后一位（1为非，0为是），如150表示为`10010110 00000001`，16进制转写为`96 01`. 注：此类型非SSH消息定义. 6. 具体实现 6.1. 数字签名算法选择在本设计中, 我们将使用SSH密钥对QSL卡片上的信息进行数字签名, 这是因为SSH的签名消息相比于PGP签名后的消息更小, 更易于在QSL卡片上展示. 对于具体的算法选择, 我们使用Ed25519椭圆曲线密码, 这是因为Ed25519的公钥大小和签名大小都足够小, 可以更方便地嵌入在QSL卡片中. 签名内容不包含被签名的信息. 6.2 数字签名有效载荷ADIF 数字签名的有效载荷为一ADIF文件, 其可以从QSL卡片上所展示的信息唯一构造. 6.2.1 构造ADIF 被数字签名的信息使用ADIF格式, 它人类可读的特性使得它可以被简单地构造, 同时由于数字签名不包含被签名的信息, 被签名信息的长度对签名的长度没有影响. 以下信息会**依次**包含在ADIF数据当中： > - QSO_DATE > - TIME_ON > - BAND > - CALL > - MODE > - STATION_CALLSIGN > - OPERATOR 其中, `QSO_DATE`为8位数字（年、月、日）表示的协调时（UTC）日期, `TIME_ON`为6位数字（时、分、秒）表示的协调时（UTC）时间, 无论QSL卡片上是否印刷出了通联的秒数, 时间都应*截断*至整分钟（即将秒数简单置0）. 上述各项均**应**用大写字母.如果QSL卡片上没有指明操作员, 则`OPERATOR`为不含任何修饰的`STATION_CALLSIGN`. 如, 以下的QSL卡片： ``` TO BB0BBB DE B4/BG6TOE Date Time (BJT) / Freq / Mode / RST 2023-01-01 02:00:59 14.245 MHz USB 59 59 [x]PSE [ ]TNX QSL VY TU! 73 ``` 其ADIF转写为: ``` 2022123118000020MBB0BBBUSBB4/BG6TOEBG6TOE ``` 该文件的`xxd`转储为: ``` 00000000: 3c51 534f 5f44 4154 453a 383e 3230 3232 2022 00000010: 3132 3331 3c54 494d 455f 4f4e 3a36 3e31 12311 00000020: 3830 3030 303c 4241 4e44 3a33 3e32 304d 8000020M 00000030: 3c43 414c 4c3a 363e 4242 3042 4242 3c4d BB0BBBUSBB4/ 00000060: 4247 3654 4f45 3c4f 5045 5241 544f 523a BG6TOEBG6TOE ``` 需要注意：文末**不应**有任何多余字符（含换行、空格、制表符等）, 即``后不含有任何字符. 6.2.2 构造含有多个QSO的ADIF信息若一张QSL卡片上含有多个QSO, 则对应的ADIF文件**应**按照通联的时间顺序, 直接拼接各个QSO的ADIF数据，文末**不应**有任何多余字符（含换行、空格、制表符等）, 即, 以最后一个QSO的``后不含有任何字符. 6.3 签名数据 6.3.1 展示方式签名数据**可以**在经由Base64编码后直接显示在QSL卡片上. 以文本形式表示的签名数据**宜**使用等宽字体排版. 使用的字体**应**足以分辨`i`、`l`、`1`, `O`、`o`、`0`， `5`、`S`等Base64使用的编码字符. 签名数据**可以**在经由Base32编码后直接显示在QSL卡片上. 以文本形式表示的签名数据**宜**使用等宽字体排版. 签名数据**宜**在经由Base45编码后包含于QR Code中. 此时签名数据**应**为独立的二维码. 该二维码**可**使用除黑、白之外的颜色, 但**应**用浅色区域作为二维码背景、深色作为二维码前景色. 为保证生成二维码识别成功率, 使用QR Code为载体的签名数据**不宜**使用Base45以外的编码. 6.3.2 二进制签名数据格式二进制签名为SSH签名结构体, 其格式为： ``` byte[6] MAGIC_PREAMBLE uint32 SIG_VERSION ssh-string publickey ssh-string namespace ssh-string reserved ssh-string hash_algorithm ssh-string signature ``` 其中：`MAGIC_PREAMBLE`为`SSHSIG`, `SIG_VERSION`为1. `publickey`为序列化后的签名密钥的公钥. `namespace`**应**为`adif-qslv1`. `reserved`**应**为空. `hash_algorithm`**应**为`sha512`(即, 总是使用SHA512对数据进行签名). `signature`为SSH正文的签名, 使用`ssh-ed25519`算法. 6.3.3 签名的精简为了使得签名内容更容易被展示，**可以**对签名内容进行精简。精简之后的签名仅包含头部及ED25519签名数据。其中，头部固定为`DQSLV1`，后紧跟64字节的ED25519签名`X||Y`。当接收方获得开头为`DQSLV1`的签名数据时，**应**将其展开为标准签名格式进行校验。 6.3.4 被签名内容实际被签名的内容为： ``` byte[6] MAGIC_PREAMBLE ssh-string namespace ssh-string reserved ssh-string hash_algorithm ssh-string H(message) ``` 其中：`MAGIC_PREAMBLE`为`SSHSIG`, `SIG_VERSION`为1. `publickey`**应**为序列化后的签名密钥的公钥.`namespace`**应**为`adif-qslv1`. `reserved`**应**为空. `hash_algorithm`**应**为`sha512`(即, 总是使用SHA512对数据进行签名). `message`4.2 节所描述的ADIF文件, `H(message)`为其SHA-512算法下的指纹. 将此内容经由SSH Message格式编码后, 使用Ed25519私钥和`ssh-ed25519`进行签名，即得到4.3.1节中的`signature`字段. 7. 附加原始QSO数据签名前可附加原始QSO数据，以方便机器直接识别、校验。原始QSO数据为精简表示的极小QSO元数据，包含以下字段：通联时间、通联波段、通联模式、收方呼号、发方呼号、OP。其格式为： ``` byte[6] MAGIC_PREAMBLE varint call varint station_callsign varint operator ssh-string data ``` 其中，call、station_callsign、operator为呼号的37进制数表示（见下表）： ``` +---------++----+----++----+----+ |Char|Num ||Char|Num ||Char|Num | +---------++----+----++----+----+ | 0 | 0 || C | 12 || O | 24 | | 1 | 1 || D | 13 || P | 25 | | 2 | 2 || E | 14 || Q | 26 | | 3 | 3 || F | 15 || R | 27 | | 4 | 4 || G | 16 || S | 28 | | 5 | 5 || H | 17 || T | 29 | | 6 | 6 || I | 18 || U | 30 | | 7 | 7 || J | 19 || V | 31 | | 8 | 8 || K | 20 || W | 32 | | 9 | 9 || L | 21 || X | 33 | | A | 10 || M | 22 || Y | 34 | | B | 11 || N | 23 || Z | 35 | | / | 36 |+----+----++----+----+ +----+----+ ``` 如`B1CRA`表示为`11 * 37^4 + 1 * 37^3 + 12 * 37^2 + 27 * 37 + 10 = 20683861` 其中，data为多个最小QSO拼接而成的字符串，其格式为 ``` varint QSO Timestamp varint Band byte[8] Mode ``` 其中QSO Timestamp为协调时1970年元旦以来的秒数（但精确到分钟）。Band为波段对应频率的低端（千赫兹）数，如20米波段表示为14000。Mode为表示模式的字符串，不足8字节用`\0`补全。 8. 示例假设 `ST4TION` 使用电台 `C3SHI` 与 `TE5T` 在北京时2023年1月1日10:05:30，在20米段上使用MFSK调制方式完成了一次通联完成了一次通联. 现`ST4TION`欲以其自己名义签名如下QSL卡片: ``` TO TE5T DE C3SHI OP ST4TION Date Time (BJT) / Freq / Mode / RST 2023-01-01 10:00 14.074 MHz MFSK 59 59 [x]PSE [ ]TNX QSL VY TU! 73 ``` `ST4TION`的私钥为: ``` -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW QyNTUxOQAAACADTnJZ6blw4CsqVoxzv9iWVVl0ycM8Neqb9QvTyvKqCAAAAJiuWf0orln9 KAAAAAtzc2gtZWQyNTUxOQAAACADTnJZ6blw4CsqVoxzv9iWVVl0ycM8Neqb9QvTyvKqCA AAAEDgyhqzLTK6rmVqjfvHpvHPYJzdeVuDhRo93XO98jDl1QNOclnpuXDgKypWjHO/2JZV WXTJwzw16pv1C9PK8qoIAAAAFW1hdHN1QEJHNlRPRS1Ob3RlYm9vaw== -----END OPENSSH PRIVATE KEY----- ``` 其公钥为: ``` ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIANOclnpuXDgKypWjHO/2JZVWXTJwzw16pv1C9PK8qoI ``` 则其构造如下的ADIF数据(签名有效载荷): ``` 2023010102050020MTE5TMFSKC3SHIST4TION ``` 需要注意: - 卡面上的北京时间应转换为协调世界时 - 生成的ADIF文件中的秒被无条件截断至0 - 波段从14.074得出, 为20M - RST不包含在ADIF当中该ADIF的`SHA512`指纹为: ``` 5d10 5c01 843a 14ad 9852 5f40 f9e9 36d5 0e00 56b0 d98b a04f 6d1d d337 efb8 11bb f397 52d3 6233 6b64 ab8f 430f cf6b e95d bfb4 39b9 26c8 fb39 9cbf 414a b386 a1b4 ``` 构造如下被签名数据: ``` 00000000: 5353 4853 4947 0000 000a 6164 6966 2d71 SSHSIG....adif-q 00000010: 736c 7631 0000 0000 0000 0006 7368 6135 slv1........sha5 00000020: 3132 0000 0040 5d10 5c01 843a 14ad 9852 12...@].\..:...R 00000030: 5f40 f9e9 36d5 0e00 56b0 d98b a04f 6d1d _@..6...V....Om. 00000040: d337 efb8 11bb f397 52d3 6233 6b64 ab8f .7......R.b3kd.. 00000050: 430f cf6b e95d bfb4 39b9 26c8 fb39 9cbf C..k.]..9.&..9.. 00000060: 414a b386 a1b4 AJ.... ``` 应用前述私钥及`ssh-ed25519`签名方式进行签名: ``` 00000000: 0000 0053 0000 000b 7373 682d 6564 3235 ...S....ssh-ed25 00000010: 3531 3900 0000 4082 84f9 edcb 8ef8 6cdf 519...@.......l. 00000020: 5bee c347 6762 84ea ce4b 4644 6429 6900 [..Ggb...KFDd)i. 00000030: 4139 6e79 9bbd f74c 2b94 0e53 541e 4dfa A9ny...L+..ST.M. 00000040: 94db 704a 9b77 aad1 4dcd 2e5d 6b3f 30c6 ..pJ.w..M..]k?0. 00000050: 44c6 7e84 ca4d 07 D.~..M. ``` 构造签名: ``` 00000000: 5353 4853 4947 0000 0001 0000 0033 0000 SSHSIG.......3.. 00000010: 000b 7373 682d 6564 3235 3531 3900 0000 ..ssh-ed25519... 00000020: 2003 4e72 59e9 b970 e02b 2a56 8c73 bfd8 .NrY..p.+*V.s.. 00000030: 9655 5974 c9c3 3c35 ea9b f50b d3ca f2aa .UYt..

技术有点深奥看不懂（我想问一下，数字签名是和电子qsl卡一起发送一张卡片文件和一份签名文件还是直接发送卡片文件，其中包含数字签名怎么感觉有点像电子发票的发票章hhh

@"YofoaStudio"#p2914 不是对QSL卡签名，而是对卡上的信息签名所以可以嵌入也可以分开其实就是类似于发票上那个东西

@"BG8LGP"#p2928 在写因为是标准的ssh签名所以也可以构造好adif文件之后用ssh来签 `ssh-keygen -Y sign -f ~/.ssh/id_ed25519 -n adif-qslv1 qsos.adif`

之前想过 GPG，但是产物太大了不好弄到卡片上，蹲楼主一套程序

@"BG2ELG"#p2932 我之前也考虑过用GPG，事实上我有用过GPG签QSL，也是因为签名太大了放弃我最终的想法是能够用针式打印机打在卡片上，激光或者喷墨打印机印这个二维码肯定绰绰有余，热转印可能跟针式打印机效果差不多？用Base45也是为了能有更小的二维码尺寸（10个Bit对应二维码上11个像素）效率高达91% 我也在考虑用Datamatrix或者PDF417（等我搞一个针式打印机测试一下）这个RFC主要目的还是定义数字签名的内容和方法，因为我觉得肯定要避免QSL正文编码进二维码，但这样就要求能确定性地根据卡面信息手搓被签名的内容

@"erjiaqing"#p2931 我在研究基于区块链的通联日志记录与eQSL交换的实现方法，你这个项目正好对应了我的签名与验证模块。或许可以一起研究研究？

@"BG8LGP"#p2937 可以啊我正好也在思考DigitalQSL与公钥的交换方式

[RFC] QSL 卡片的數位簽名

erjiaqing

AD2AG

SSH簽名有意刪除了時間戳，這是因為一旦私鑰洩漏，時間戳就可以隨意偽造，因此在檔案簽名的時間戳並沒有任何意義。

那麼，有哪些方法可以解決時間戳的問題呢？

收集一批 QSL 卡，一起丟一個時間戳 CA，成本幾乎可以忽略。
鏈上——根據區塊鏈共識演算法，有些區塊鏈的產出時間大致固定，因此可以用作時間戳。
傳統方法——郵戳……

BI1QGF

SSH簽名是一種終端到端的簽名演算法，它對 RSA、ECC 等進行了封裝。設計文件中有詳細說明為何採用這種設計，以避免常見應用中的問題。

AD2AG

erjiaqing
感覺不需要擔心憑證洩漏的問題。如果憑證被洩漏，整個簽名都可能被偽造，不僅僅只是時間戳。而且保護憑證的責任在於使用者，而不是開發者。一旦憑證被洩露，應該立即發起撤銷憑證。

「時間戳」似乎並不是一個重要的東西，只是為了符合 OpenPGP 的簽名要求而加入。相較於使用 SSHSIG，我更傾向於使用 OpenPGP 系統，原因如下：一是鍵可以設定到過期日期，二是具有信任鏈機制，可以間接實現 CA 的部分功能。當然，也可以透過 SSL 等標準來實現。SSHSIG 感覺缺少一些對鍵的控制機制，而且也不太容易與硬體鍵進行遷移。

不過，這個示範仍然相當出色。

BH3XZT

erjiaqing 目前有沒有已經完成的方案？我打算用在 POTA 通訊中國 0-9區的獎狀上試試看。
需求：1、管理員簽名
2、簽發時間
3、獎狀圖片
4、獎狀內容資訊（獲獎者的號碼、姓名）
5、獎狀編號
最終目標是透過掃描二維碼（無論是在網站、獎狀或手機上），就能顯示獎狀內容並確認其有效性。

BI1QGF

BG8LGP

我也對 OFD 標準的實施感興趣，但這個方案與現有的 eSQL 格式不相容，在推廣方面可能會遇到困難。

我曾考慮過使用 ADIF，透過應用程式定義的欄位來儲存簽名，然後將整個內容以 PDF417 編碼放在卡片上。然而，實際上並沒有支援 PDF417 的 ADIF 閱讀器。

erjiaqing

最主要的問題並不是私鑰洩漏和時間戳的可靠性，而是公開鍵的分發。

BH3XZT

在需要管理員簽署的情況下，傳統的 S/MIME 或 PGP 其實更適合。

BG9JDI

BG8LGP 天啊，你竟然還在研究這個？哈哈！

BH3XZT

這個很好，看看能不能用在 POTA 通聯中國 0-9區獎狀上。

BG8LGP

BH3XZT 這位長輩，我有一個方案可以滿足您的所有需求。

sparrowhe

BH3XZT 實際上，可以嘗試建立一個網站來公告發放情況，但它的缺點是無法進行離線驗證。

AD2AG

BH3XZT

有個小疑問，為什麼不直接使用 PDF 這種現成的解決方案呢？它可以透過程式來產生，並且可以直接包含電子簽名資訊。

需求 1 和 3 可以合併為背景圖。需求 2、4 和 5 則由程式自動產生，可以直接利用 PDF 的增量更新功能，在模板檔案的末尾新增（覆蓋）這些資訊即可。最後，對整個檔案進行簽名後再發送。

最終，獎狀上的 QR Code 應該：1) 展示獎狀內容，也就是將獎狀圖片放在 QR Code 中嗎？ 2) 有效性是指哈希 + 簽名，可以直接使用 PDF 來解決。

我不確定使用 OFD 是否是因為擔心 PDF 可能存在潛在的專利問題。 (思考)

BH3XZT

BG8LGP 喔，您說

BG8LGP

BH3XZT 一種基於 GB/T 33190-2016《電子文件儲存與交換格式版式文書》的 eQSL 卡片方案，這點啟發了我也，或許也可以用於獎狀的分發。

BG2ELG

將驗證地址移至網路 https://bit.ly/bg2elg

captive

~~標題是 RFC，而正文則是（不完全符合標準的）國家標準格式。請問您是誰？~~
這套流程適用於電子卡的簽名嗎？

BH4GDU

如果沒有第三方驗證，單憑個人聲稱就無法解決冒名問題，對嗎？

BG2ELG

BH4GDU 因此，我們又回到了關於金鑰匙發放的經典問題。

除了確認通訊，QSL 卡也能展現個人特色和分享愛好（簡單來說就是「玩」）。

BG5VQE

BH4GDU 公開的公鑰可能可以在 QRZ 上發佈。

YofoaStudio

【餅】
建議使用 hamcq 日誌系統。

Ken

需要明確的是，是要確認簽名、防偽的對象是電子 QSL 卡，還是整個聯絡過程本身。主題討論應該集中在前者。由於前者相對容易處理，無論使用成熟的 PGP，或是仿照數碼發票系統來實施一套，都是可行的。其中可能遇到的困難在於呼號所有者的真實性驗證，如果必須驗證，則可能需要與各國主管機構的系統對接，或建立類似 DMR ID 的第三方驗證機構。相比之下，我認為對整個聯絡過程進行簽名，可能比對電子 QSL 卡進行簽名更有意義，否則仍然會存在雙方合作製作不對應到真實聯絡的情況。然而，除非像電子郵件的 PGP MIME 或 Crypto Coin 那樣，被簽名的對象就是被驗證的對象本身，否則都會像各種食品追溯碼類項目一樣，存在被簽名的對象與被驗證的對象之間的映射關係真實性問題。除非改造現有的收發設備，否則周圍的機制無法確保這次聯絡是真實發生的。

BG7QVU

【餅】
我之前看到一些國外護照證件影片分享，以及在衛星上有些「OM通」的次數非常多，所以想看看自己是否也能這樣做。國際民用航空組織（ICAO）的文件 9303 將幾張 QSL 卡製作成護照的形式。~~（機讀碼頁上的資訊，後面一個 QSO 就貼一張貼紙當簽證）~~正好買到一大堆容量足夠的 RFID 標籤，應該可以將「通聯資訊」等內容寫入標籤內。~~然後，只差把 QSL 卡給閘門掃描，再用指紋或臉部辨識開門即可。~~

附件 E 的截圖（第 10 部分）：將「旅行記錄」和「簽證記錄」改為「設備記錄」，基本上就可以了。

第九部分的第十二部分中，關於簽發國之間交換密鑰、簽名等內容，確實比較複雜。

« 上一页

闽ICP备2021006864号-7

闽公网安备35020602002794号互联网举报中心

用户协议隐私政策社区规范积分规则中继规则转载须知
更新日志联系我们常见问题友情链接运营报告赞助

浩奇科技（厦门）有限公司

是无线电，把我们联系在一起