CZ301362B6

CZ301362B6 - Zpusob ke kontrole platnosti digitálních záznamu o frankování

Info

Publication number: CZ301362B6
Application number: CZ20033555A
Authority: CZ
Inventors: Delitz@Alexander; Fery@Peter; Helmus@Jürgen; Höhl@Aloysius; Meier@Gunther; Robel@Elke; Stumm@Dieter
Original assignee: Deutsche Post Ag
Priority date: 2001-07-01
Filing date: 2002-06-28
Publication date: 2010-01-27
Also published as: JP2005508537A; HRP20031076B1; WO2003005307A1; ZA200400093B; NO20035858L; CN100388306C; BG108505A; PL369445A1; BG64913B1; DE10131254A1; EP1405274A1; CZ20033555A3; SK16272003A3; HK1065146A1; EP1405274B1; HRP20031076A2; RU2003137601A; ATE343830T1; NO325464B1; YU101803A

Abstract

Pri zpusobu ke kontrole pravosti záznamu o frankování, umísteného na poštovní zásilce, se v záznamu o frankování obsažená šifrovací informace používá dekódovaná a ke kontrole pravosti záznamu o frankování. Zpusob se vyznacuje tím, že ctecí jednotka zachycuje záznam o frankování graficky a predává ho na kontrolní jednotku, a že kontrolní jednotka rídí prubeh dílcích kontrol.

Description

Způsob ke kontrole platnosti digitálních záznamů o frankování

Dosavadní stav techniky

Je známé, že poštovní zásilky se opatřují digitálními záznamy o frankování.

Aby se odesilatelům poštovních zásilek ulehčilo vytvoření záznamů o frankování, je například u frankovacího systému užívaného Deutsche Post AG možné, vytvářet v zákaznickém systému io záznamy o frankování a vydávat je přes libovolná rozhrání na tiskárnu.

Aby se zabránilo zneužití tohoto způsobu, obsahují digitální záznamy o frankování šifrovací informace, například o identitě zákaznického systému, řídícího zhotovení záznamu o frankování.

Vynález má za úkol, vytvořit způsob, kterým se nechá rychle a spolehlivě kontrolovat pravost záznamů o frankování. Způsob se zejména hodí pro kontrolu ve velkosériovém použití, zejména v dopisových nebo přepravních střediscích.

Podstata vynálezu

Podle vynálezu se tento úkol řeší tím, že Čtecí jednotka graficky zachycuje záznam o frankování a předává ho na kontrolní jednotku a že kontrolní jednotka řídí průběh dílčích kontrol.

Zejména je účelné, že jedna z dílčích kontrol zahrnuje dekódování šifrovacích informací, obsažených v záznamu o frankování.

Pomocí integrace dekódování šifrovacích informací do kontrolního procesu je možné, bezprostředně zachycovat pravost záznamů o frankování, takže se může uskutečňovat kontrola online jo zejména během průběhu zpracování poštovní zásilky ve zpracovávacím stroji.

Dále je výhodné, že jedna z dílčích kontrol obsahuje porovnání mezi datem vytvoření záznamu o frankování a aktuálním datem. Integrace data vytvoření záznamu o frankování - zejména v zakódovaném tvaru - zvyšuje zabezpečení dat, protože porovnáním mezi datem vytvoření záznamu o frankování a aktuálním datem se zabraňuje několikanásobnému použití jednoho záznamu o frankování k přepravě poštovních zásilek.

K dalšímu zvýšení rychlosti kontroly je výhodné, že čtecí jednotka a kontrolní jednotka sí vyměňují informace pomocí synchronního protokolu.

V jiném, rovněž účelném provedení vynálezu, komunikují čtecí jednotka a kontrolní jednotka spolu přes asynchronní protokol.

Přitom je zvlášť účelné, že čtecí jednotka posílá datovou zprávu na kontrolní jednotku.

Datová zpráva přednostně obsahuje obsah záznamu o frankování.

Přehled obrázků na výkresech

Vynález bude blíže vysvětlen prostřednictvím konkrétních příkladů provedení znázorněných na výkresech, na kterých představuje obr. 1 principiální znázornění systémových komponent systému zajištění úhrady;

- 1 CZ 301362 B6 obr. 2 zvláště přednostní provedení systému zajištění úhrady, ručního skeneru a PC zajištění úhrady;

obr. 3 principiální znázornění vytváření a kontroly záznamů o frankování;

obr. 4 přehled komponent šifrovacího systému; obr. 5 přednostní provedení způsobu kontroly;

io obr. 6 další zvláště přednostní provedení způsobu kontroly zvláště přednostním průběhem dílčích kontrol;

obr. 7 přednostní průběh rozdělení kódů mezi centrálním místem zavádění (Postage Point) a jednotlivými šifrovacími kontrolními jednotkami (Crypto Server),

Příklady provedeni vynálezu

Vynález se následovně znázorňuje na příkladu PC-frankovacího systému. Kroky způsobu sloužilo cí k zajištění úhrady jsou přitom nezávislé na systému, použitém k vytváření záznamů o frankování.

Znázorněná decentralizovaná kontrola na jednotlivých kontrolních místech, zejména v dopisových střediscích, je zvláště přednostní, centralizovaná kontrola je ale stejně možná.

V prvním provedení vynálezu se uskutečňuje přednostně kontrola pravosti záznamů o frankování namátkově pomocí jednotlivých skenerů.

K tomu vhodný kontrolní systém obsahuje přednostně komponenty, obsažené na obr. 1.

Na obr. 1 je znázorněno, se kterými dílčími systémy je šifrovací systém v kontaktu. V dalším se krátce popisují.

Skener

Skenery slouží k načtení záznamu o frankování PC-frankování. U záznamů o frankování se jedná o 2D-kódy ve formátu datové matice, s použitou opravou chyb ECC200. Podle typu skeneru se data přenášejí rádiem nebo kabelem, přičemž radiové skenery disponují vícemístným displejem a tím možností výstupu a dotekem ovládanou obrazovku, popřípadě klávesnicí k rudimentárnímu zadávání. Rozhraní mezi skenery a zbývajícími systémy přednostního systému zajištění úhradyPC-frankování tvoří Scanner Controller a Validation-Controller jako složky. Zatímco Scannerer-Controller spravuje Queue maticových kódů, které přicházejíce přes ruční skener ke kontrole a v podstatě udržují kontakt ke skenerům, je s dalším systémem v kontaktu jen přes ValidationScanner.

Scanner Controller/Validation-Controller

Scanner Controller, popřípadě Validation-Controller slouží jako rozhraní mezi skenery a dalšími systémy ke kontrole 2D-čárového kódu. Předává se jim obsah 2D-čárového kódu, přeměněný z optického zachycení a s opravenými chybami, a tyto zařizují potom kontrolu a v případě radiového skeneru se starají o výstup výsledku čtení a kontroly a slouží jako rozhraní mezi eventuálně nutnými manuálními dodatečnými zpracováními a kontrolami kontrolora a ostatními systémy.

-2CZ 301362 B6

Šifrovací systém

Šifrovací systém slouží k obsahové a šifrovací kontrole obsahu 2D“čárového kódu jakož i pro chráněné ukládání bezpečnostně relevantních dat a algoritmů. K jednotlivým složkám se pristu5 puje později.

Místo zavádění obnosu poplatku (Postage Point)

Místo zavádění obnosu poplatku (Postage Point) je centrální systém v PC-frankování. Slouží 10 jako rozhraní k zákaznickým systémům. Od něho mohou zákazníci uvolňovat předvolené obnosy k následujícímu frankování. V místě zavádění obnosu poplatku (Postage Point) se generují kódy k zajištění způsobu. Dále slouží jako rozhraní k zúčtovacím systémům. Následující rozhraní se dávají k dispozici přednostnímu systému zajištění úhrady k PC-frankování:

· vysílací informace o 2D-čárovém kódu • symetrické kódy • kmenová data, jako např. předvolené obnosy, stavy kont Přednostní centrála zajištění úhrady

V přednostním systému centrály zajištění úhrady se sbírají informace vztažené k zásilce a dávají se k dispozici ostatním systémům. Zde dochází ke zhotovení výrobních zpráv, které opět vedou ke zhotovení negativních souborů. Systém centrály zajištění úhrady dále dostává od místa zavádění obnosu poplatku (Postage Point) aktuální kódovací data a předává je na jednotlivé šifrovací servery.

Poskytovatelé dat

K obsahové kontrole 2D-čárových kódů je nutná rada kmenových dat, jako například negativní 30 soubory, minimální úhrady, časová období platnosti vzhledem k produktu a kódy výstrahy zajištění úhrady a následného zpracování. Tato data se dávají k dispozici z různých systémů (BDE,

VIBR1S, lokální systém zajištění úhrady).

Aplikace zajištění úhrady

S aplikací zajištění úhrady má AGB-kontrolor, který musí dodatečně zpracovat vyřazené PCfrankované zásilky, možnost provádět detailní kontrolu frankování, při které se znázornění výsledků kontroly neomezuje ohraničenými výstupními možnostmi skeneru. Kontrolor zde může dodatečně vidět i další data, jako časové období platnosti poštovného, kterého se týká aktuální zásilka, jakož i obnos a požadované frankování.

Automatické zaznamenání 2D-čárového kódu

Automatické zaznamenání 2D-Čárového kódu se uskutečňuje uvnitř SSA, K tomu se předávají 45 obrazové informace na AFM-2D čtečku kódů. Tam se uskutečňuje konverze obrazu na obsah kódu datové matice. V souvislosti s tím se přenáší 2D-obsah čárového kódu na Šifrovací systém ke kontrole, vrácený výsledek kontroly se vyhodnocuje a předává se na optický záznamový systém (IMM) ke kódování zásilky. Přednostní součásti takovým způsobem rozšířeného způsobu kontroly jsou znázorněné na obr. 2.

AFM-2D čtečka kódu

Na jeden Čtecí stroj (ALM/ILVM) existuje jedna AFM-2D čtečka kódu, která přes optický záznamový systém (IMM) získává a pro účely zajištění úhrady dále zpracovává obrazová data

-3CZ 301362 B6 zásilek. V rámci přednostního zajištění úhrady-PC-fran kování znamená toto v případě rozpoznaného 2D-kóau, že z obrazových dat se extrahuje 2D-data maticový kód a při užití způsobu opravy chyb ECC200 přeměňuje na byte řetězec, který znázorňuje obsah 2D-čárového kódu,

Tento bytový řetězec se předává na Validation Controller ke kontrole. Výsledek kontroly se následovně předává přes rozhrání optického záznamového systému a tam se používá ke kódování, Šifrovací systém pro AFM-2D čtečku kódu.

io Podle vlastností šifrovacích karet se může například počítat s přibližně 27 kontrolami za sekundu. Protože rychlost čtecích strojů leží u přibližně 10 přečtených zásilek za sekundu, ukazuje se, že nemá smysl, každou AHM-2D čtečku kódu kombinovat s šifrovacím systémem. K tomu se přidává, že se také nenechá vycházet z toho, že PC-F-zásilky se na sto procent vytvářejí na všech strojích současně. Proto se jeví smysluplné, separovat šifrovací systémy a několik PC -F-čteček is provozovat s šifrovacím systémem. Řešení by mělo být přitom zvoleno tak, že se nechá měnit měřítko, tedy je možných několik šifrovacích systémů na dopisové středisko. Toto je například relevantní pro dopisová střediska s vysokým výskytem zásilek a vysokým počtem čtecích strojů, u kterých se na počátku nechá navrhovat druhý šifrovací systém. K tomu se později v provozu může počet serverů při příslušné potřebě zvyšovat.

Architekturu je ke zmenšení složitosti přitom třeba volit tak, že jednotlivé čtecí stroje jsou pevně přiřazené šifrovacímu systému a eventuálně se rozšiřují ještě o dodatečnou Fallback-konfiguraci, která v případě chyby zkouší vybočit k jinému šifrovacímu systému.

Oddělení šifrovacího systému a AFM-2D čtečky kódu přináší k tomu výhodu, že nejenom strojové čtení ale i kontrola ručními skenery se může uskutečňovat se stejným šifrovacím systémem, a proto se stejná funkce nemusí implementovat dvakrát, což dodatečné nabízí i podstatné výhody při implementaci vynálezu.

Přednostní kroky způsobu k opatření poštovní zásilky digitálním záznamem o frankování po zavedení obnosu poplatku centrálním místem zavádění (Postage Point) a vytvoření záznamu o frankování pomocí lokálního PC jakož i následovně doručení poštovní zásilky a kontrola záznamu o frankování, umístěného na poštovní zásilce, jsou znázorněné na obr. 3.

Nezávisle na rozdělení kódů se postup uskutečňuje tak, že zákazník nejdříve na svůj PC zavádí obnos poštovného. K identifikaci dotazu se přitom generuje náhodné číslo. Na místě zavádění obnosu poplatku (Postage Point) se vytváří nový obnos poštovného k příslušnému zákazníkovi a z předaného náhodného čísla, dalších informací k identitě zákaznického systému (identifikační údaj zákaznického systému, v dalším zvaný Postage ID) a k obnosu poštovného se vytváří tak40 zvaný šifrovací řetězec, který se kóduje tajným symetrickým kódem, existujícím na místě zavádění obnosu poplatku (Postage Point).

Tento šifrovací řetězec a příslušný obnos poštovného se následně přenášejí na zákaznický PC a spolu s náhodným číslem se ukládají v jeho „Safe-Box“ zabezpečeně před nežádoucími přístu45 py.

Pokud zákazník ve spojení s tímto postupem frankuje obdrženým obnosem poštovného poštovní zásilku, data zásilky relevantní pro 2D-čárový kód, mimo jiné šifrovací řetězec, datum frankování a frankovací obnos, se rozšiřují o náhodné číslo a Postage ID se shromažďuje v nezakódovalo ném tvaru, a vytváří se transformační hodnota, která jednoznačně identifikuje obsah.

Protože náhodné číslo existuje v zakódovaném tvaru uvnitř šifrovacího řetězce jakož i v nezakódovaném tvaru uvnitř transformační hodnoty, zajišťuje se, že data zásilky se nemění, popřípadě se mohou generovat libovolně, a je možné vrácení zhotoviteli.

-4CZ 301362 B6

Relevantní data k zásilce se potom následně přeměňují na 2D-čárový kód a jako příslušná frankovací značka se pomocí tiskárny zákazníka tiskne na zásilku. Hotová zásilka se potom může dát do poštovního oběhu.

U zvláště přednostního provedení zajištěni úhrady se 2D-ěárový kód čte a následně kontroluje v dopisovém středisku AFM-2D čtečkou kódu, popřípadě ručním skenerem. S tím spojené kroky procesu se stávají zřetelnými v zobrazení pod čísly 5-8 procesu. Ke kontrole správnosti 2Dčárového kódu přesouvá AFM-2D čtečka kódu kompletní data zásilky na šifrovací systém. Tam se dekóduje šifrovací informace, zejména šifrovacího řetězce, obsažená v datech zásilky, aby se ío zjistilo náhodné číslo, použité při zhotovení transformační hodnoty.

V souvislosti s tím se zjišťuje transformační hodnota (zvaná také Message Dígest) k datům zásilky včetně dekódovaného náhodného čísla, a kontroluje se, zda je výsledek identický s transformační hodnotou obsaženou v 2D-čárovém kódu.

Dodatečně k šifrovací validaci se uskutečňují ještě další obsahové kontroly (číslo 7b procesu), které například vylučují dvojité použití jednoho 2D-Čárového kódu, popřípadě kontrolují, zda se zákazník stal nápadným kvůli pokusům o podvod a proto je uveden v negativním souboru.

Příslušný výsledek kontroly se potom předává na PC-F-ětečku, která předává výsledek na optický záznamový systém (IMM) ke kódování čárového kódu. Čárový kód se hned potom tiskne na dopis a zásilky se při negativním výsledku kontroly vyřazují.

Architektura šifrovacího systému:

Přehled složek

Obr. 4 dává přehled o dílčích složkách Šifrovacího systému, přičemž popsané šipky znázorňují vstupní a výstupní toky dat k externím systémům. Protože přednostní centrální systém zajištění úhrady se používá jako otáčivý kotouč při rozdělování kódů místa zavádění obnosu poplatku (Postage Point) na šifrovací systémy lokálních systémů zajištění úhrady a tato data se musí ukládat do vyrovnávací paměti, je tam rovněž třeba navrhnout složku šifrovacího systému, u které se ale Validation Controller zpravidla nepoužívá.

Dílčí složky Šifrovacího systému se v dalším popisují detailněji.

Validation Controller

Validation Controller představuje rozhraní ke kontrole kompletního obsahu 2D-čárového kódu.

Kontrola 2D-čárového kódu sestává z obsahové kontroly a z šifrovací kontroly. Za tímto účelem by načtený obsah 2D-čárového kódu měl skenerem předávat pomocí Scanner Controller na Validation Controller.

Protože se příslušný Scanner Controller pro, dráty spojený, skener a Validation Controller nachá45 zejí na různých počítačových systémech, je možné mezi nimi navrhnout komunikaci založenou na TCP/IP, přičemž místo Čistého Socket-programování nabízí použití na něj posazeného protokolu výhody. V rámci šifrovacího systému zde přichází do úvahy manažer zpráv, použitý v záznamu provozních dat (BDE), nebo protokol jako Corba/HOP, použitý v rámci optického záznamového systému.

Validation Controller inicializuje jednotlivé kontrolní rutiny, které opět předávají zpět jejich kontrolní výsledky.

Protože je několik AGB-kontrolorů současně činných s různými skenery, je třeba Validation

Controller dimenzovat aby byl schopný „multisession“. To znamená, musí uskutečňovat souČas-5CZ 301362 Bó né kontrolní dotazy a příslušný výstup umět řídit na správný skener. K tomu by měl být dimenzován tak, že současné k tomu může paralelně provádět několik kontrolních dotazů jakož i část kontrolních kroků, například kontrolu transformační hodnoty a kontrolu minimální úhrady.

Na začátku relace se kontroléru sděluje, se kterým typem skeneru komunikuje, a dostane přiřazenou možnost, pomocí CallBack-metody ovládat rutiny k výstupu a k manuální dodatečné kontrole. Podle typu provozu a typu skeneru se výsledky potom vydávají bud* na radiový skener nebo na systém zajištění úhrady, jakož se i zaznamenávají manuální výsledky kontroly.

ío Šifrovací karta

Zvláštní problematika spočívá v uschovávání kódu, kterým se šifrovací řetězec musí kódovat v 2D-čárovém kódu a ke kontrole zase dekódovat. Tento kód zajišťuje zabezpečení 2D-čárového kódu proti padělání a proto nesmí být možné ho vyslídit. Proto musí být zajištěné speciálními bezpečnostními opatřeními, že tento kód není nikdy viditelný v Dešifrovaném textu na pevném disku, v paměti nebo při přenosu a k tomu je zabezpečen silnými šifrovacími způsoby.

Čistě na software založená řešení zde nepřinášejí spolehlivé zabezpečení, protože na libovolném místě v systému se přece objevuje kód v nešifrovaném textu, nebo by kód mohl být přečten ladi2o cím programem v nešifrovaném textu v paměti. Toto nebezpečí existuje především také tím, že systémy mohou být administrovány na dálku, popřípadě se za účelem opravy eventuálně dávají mimo firmu.

Šifrovací způsoby k tomu vytvářejí vysoké zatížení procesoru systému, který není optimální vzhledem k probíhajícím operacím.

Proto se doporučuje použití šifrovací procesorové karty s následujícími charakteristikami:

• Speciální šifrovací procesor k urychlení šifrovacích způsobů • Uzavřený Black-Box-systém k zabránění přístupu k bezpečnostně kritickým datům a způsobům.

U karet, které splňují tyto znaky, se jedná o autarkické systémy, které jsou podle provedení spoje35 né přes PCI- nebo ISA-sběmici s počítačem a přes řídicí obvod komunikují se softwarovými systémy na počítači.

Vedle baterií zálohované hlavní paměti mají karty také Flash-Rom-paměť, ve které se může ukládat individuální aplikační kód. Přímý přístup na hlavní paměť karet není od vnějších systémů možný, čímž je zaručeno vysoké zabezpečení, protože ani kódová data ani šifrovací způsoby k poskytnutí zabezpečení se nenechají dosáhnout jinak než přes zabezpečený řídicí obvod.

Karty dodatečně kontrolují pomocí vlastních čidel, zda existují pokusy o manipulaci (podle provedení karet, například teplotní špičky, záření, otevření ochranného krytu, napěťové špičky).

Pokud existuje takový pokus o manipulaci, bateriově zálohovaný obsah hlavní paměti se ihned maže a provádí se Shutdown karty.

Pro šifrovací server by se měla přímo na kartu zavádět funkce k dekódování Postage ID, funkce ke kontrole transformační hodnoty jakož i funkce k importu kódových dat, protože tyto rutiny mají vysokou relevanci zabezpečení.

Dále by se měly všechny šifrovací kódy, jakož i konfigurace certifikátů, které jsou nutné k provádění autentifikace, rovněž zabezpečovat v bateriově zálohované paměti karty. Pokud karta nedis55 ponuje dostatkem paměti, existuje na kartě zpravidla Master Key, kterým se kódují nahoře

-6CZ 301362 B6 uvedená data a následovně se mohou ukládat na pevném disku systému. Toto ale vyžaduje, že před použitím těchto informací se data nejprve opět dekódují.

Následující tabulka dává přehled v úvahy přicházejících modelů karet různých výrobců a uvádí 5 zároveň jej ich certifikace.

Šifrovací karty pro použití v přednostním systému zabezpečení úhrady pro PC-frankování

Výrobce	Typové označení	Certifikace
IBM	4758-023	FIPS PUB 140-1 Level 3 a SKA-eCash
IBM	4758-002	FIPS PUB 140-1 Level 4 a ZKA-eCash (předb. 07/2000) CCEAL 5 (v řízení, t. č. ve fázi certifikace)
Utimaco	šifrovací server	ITSEC-E2 a ZKA-eCash
Utimaco	šifrovací server 2000 (k dispozici cca.lQ/01)	FIPSPUB 140-1 Level 3, ITSEC-E3 a ZKA-eCash (v řízení)
Racal/Zaxus	WebSentry PCI	FIPS PUB 140-1 Level 4

Vedle splnění požadavků kladených na kartu je kvůli žádané certifikaci pomocí BSI také velmi to důležité, jaké certifikace toho času mají jednotlivé modely a jaké certifikace se toho času nacházejí v procesu vyhodnocování.

Certifikáty vystavené pro produkty se přitom dělí na tři stupně, provedené různými čertifikačnimi stanovišti.

ITSEC je kritériový mechanismus zveřejněný Evropskou komisí k certífíkování IT-výrobků a IT-systémů s ohledem na jejich bezpečnostní vlastnosti. Vyhodnocení věrohodnosti se posuzuje podle stupňů E0 až E6, přičemž E0 znamená nedostatečné a E6 nejvyšší zabezpečení. Další vývoj a harmonizace s podobnými mezinárodními standardy jsou CC (Common Criteria), které se toho času nacházejí v procesu standardizace u ISO (ISO norma 15408). Tento regulační mechanismus se používá k vyhodnocení zabezpečení systému.

Toho času ještě neexistuje žádný výrobek z horní tabulky, který disponuje certifikátem podle CC. IBM-model 4758-002 se ale toho času nachází v takové fázi certifikace.

Standard FIPS PUB 140-1 je kritériový mechanismus vydaný americkou vládou k posouzení zabezpečení komerčních šifrovacích přístrojů. Tento kritériový mechanismus se orientuje velmi silně na vlastnosti hardware. Vyhodnocení se uskutečňuje ve 4 stupních, u nichž Level l znamená nej menší a Level 4 největší zabezpečení.

Dodatečně k výše uvedenému standardu vyhodnocení existuje další kritériový mechanismus, který se vydává Ústředním kreditním výborem (ZKA) a reguluje schvalování pro provoz ITsystémů a produktů v oblasti electronic cash.

-7CZ 301362 B6

Vedle již zmíněných vlastností karet a příslušných čertifikování existuje ale ještě jedna řada dalších předností, které jsou v dalším krátce uvedené:

• zhotovení vlastního (signovaného) software a Upload na kartuje možný · integrovaný generátor náhodných čísel (FIPS PUB 140-1 certifikován) • DI S, Triple DES a SHA-1 jsou na straně hardware implementovány • vytvoření RSA-Key a zpracování Private/Public Key pro kódy až do délky 2048 bit • funkce Key Management • funkce managementu certifikován» io · částečně je možný provoz několika šifrovacích karet paralelně v jednom systému Šifrovací interface

Funkce bezpečnostně relevantní v rámci aplikace Šifrovacích karet se ukládají přímo v kartě i5 a jsou proto zvenku přístupné jen přes řídicí program karet. Jako rozhraní mezi řídicím programem a Validation Controller slouží složky šifrovacího rozhraní, které požadavky pro kontrolní rutiny předávají přes řídicí program na kartu.

Protože se v jednom počítači může používat několik karet, spočívá úkol šifrovacího rozhraní také v tom, že se provádí rozdělení zátěže jednotlivých kontrolních požadavků. Tato funkce je účelná zejména tehdy, když dodatečně ještě jedna nebo podle dopisového střediska několik AFM-2D čteček kódu používá kontrolní rutiny šifrovacího systému.

Další úkol spočívá v průběhu komunikace za účelem rozdělení kódových dat. Ve stupni 2 existu25 je eventuálně jenom rudimentární mechanismus, který kódy za účelem zabezpečení zakódované, přenáší uvnitř signovaného souboru. Požadavek na Šifrovací rozhraní spočívá potom v tom, dát k dispozici Utility, která umožňuje import takového souboru.

Funkce šifrovacího systému

Průběh kontroly ve Validation Controller

Ke kontrole 2D-čárového kódu se od Validation Controller dává k dispozici centrální kontrolní funkce jako rozhraní ke skenerovým popřípadě čtecím systémům. Tato kontrolní funkce koordi35 nuje průběh jednotlivých dílčích kontrol.

Kódy pro případ zajištění úhrady, přenášené z jednotlivých dílčích kontrolních rutin, se na základě předdefinované tabulky, o kterou se přednostně pečuje centrálně a přenáší se na šifrovací systém, přeměňují na příslušný kód zajištění úhrady, Uvnitř této tabulky se stanovují dodatečně priority, které regulují, který kód zajištění úhrady se přiděluje, když se rozpoznalo několik případů zajištění úhrady.

Tento kód zaj ištění úhrady se následovně dopravuje zpět jako výsledek kontroly spolu s popisujícím textem. Podle dalšího zpracovávajícího systému vně šifrovacího systému se tento výsledek vydává na radiovém skeneru nebo v aplikaci zajištění úhrady, popřípadě se pri automatické kontrole mění na TIT2-kód a potiskává se s ním zásilka.

Protože průběhy mezi systémy ručních skenerů a automatickými čtecími systémy jsou rozdílné, implementuje se pro oba případy použití rozdílná funkce.

Podle toho, jaký komunikační mechanismus se používá mezi čtecími systémy a Validation Controller, odlišuje se vyvolání a vrácení výsledků. V případě použití synchronního, na RPC založeném protokolu jako Corba/IIOP se kontrolní metoda vyvolává přímo a výsledky kontroly se

-8CZ 301362 B6 předávají po ukončení kontroly. Klient, tedy ScannerController, popřípadě čtecí systém čekají v tomto případě na provedení a vrácení výsledků kontroly. U posledního je proto třeba na klientovi navrhnout Threadpool, který může provádět paralelní kontrolu několika dotazů.

U asynchronního mechanismu pomocí TGM se kontrolní metoda nevyvolává Scanner Controller přímo, nýbrž se na šifrovací systém posílá zpráva, která obsahuje požadavky na kontrolu, obsah 2D-čárového kódu a další informace jako aktuální třídicí program. Při příchodu této zprávy na šifrovací server se kontrolní funkce vyvolává, provádí a výsledky čtení a kontroly se opět posílají zpět jako nová zpráva. Výhoda u tohoto způsobu spočívá v tom, že na požadovaném systému se proces neblokuje, dokud neexistuje výsledek.

Kontrola pro systémy ručních skenerů:

Kontrolní rutina pro systémy ručních skenerů očekává jako vstupní hodnoty Session-ID jakož i obsah 2D-čárového kódu. Jako dodatečný parametr se také ještě očekává ID třídicího programu. Poslední jmenovaný parametr slouží k určení minimální úhrady.

Obr. 5 ukazuje přehled o průběhu kontroly uvnitř Validation Controller pro případ, že se tyto vyvolávají systémem ručního skeneru. Vychází se přitom z kontroly radiovým skenerem s násle20 dujícím manuálním porovnáním adresy s 2D-obsahem čárového kódu. Lí dráty připojeného skeneru by se uskutečnilo zobrazení analogicky na systému zajištění úhrady, popřípadě na aplikaci zajištění úhrady.

Přednostní průběh kontroly pomocí použití radiového skeneru, Scanner-Controller a kontrolní jednotky (Validation Controller) je znázorněn na obr. 5.

Kontrolní jednotka řídí u znázorněného, zvlášť přednostního příkladného provedení, průběh dílčích kontrol, přičemž první dílčí kontrola zachovává přečtení maticového kódu, obsaženého v digitálním záznamu o frankování. Přečtený maticový kód se nejprve přenáší od radiového skeneru na Scanner-Controller. Následovně se uskutečňuje v oblasti Scanner-Controller kontrola maticového kódu jakož i přenos na kontrolní jednotku. Kontrolní jednotka řídí rozdělení obsahu kódu. Výsledek Čtení se následovně předává na záznamovou jednotku - ve znázorněném případě radiový skener. Tím zjistí například uživatel čtecí jednotky, že bylo možné číst záznam o frankování a přitom rozpoznat informace, obsažené v matici. Kontrolní jednotka následovně dekóduje

Šifrovací řetězec, obsažený v maticovém kódu. K tomu se přednostně nejprve kontroluje verze kódu, předběžně použitého pro zhotovení záznamu o frankování. Následovně se kontroluje transformační hodnota, obsažená v Šifrovacím řetězci.

Dále se uskutečňuje kontrola navržené minimální úhrady.

Mimoto se kontroluje identifikační číslo (Postage ID) zákaznického systému, řídícího vytváření záznamu o frankování.

Následovně k tomu se uskutečňuje porovnání identifikačního čísla s negativním seznamem.

Pomocí těchto kontrolních kroků je tímto zvláště jednoduchým a účelným způsobem možné, zjistit jednoduchým způsobem neoprávněně vytvořené záznamy o frankování.

Výsledek přenosu se přenáší jako digitální zpráva, přičemž digitální zpráva se může například přenášet na původní radiový skener. Tím může například uživatel radiového skeneru vyřadit zásilku z chodu zásilky. Při automatickém provádění této varianty způsobu je ale samozřejmě rovněž možné, zásilku vyřazovat z normálního chodu zpracování poštovních zásilek.

Výsledek kontroly se přednostně protokoluje v oblasti kontrolní jednotky.

-9CZ 301362 B6

Jako hodnota vrácení by se měl vracet kód, patřící k případu zajištění úhrady, a příslušné textové hlášení jakož i objekt 2D-čárový kód.

Průběh kontroly u AFM-2D čteěky kódu

Jako vstupní parametr kontrolní rutiny pro AFM-2D čtečku kódu se očekává rovněž relace-ID, jakož i obsah 2D-čárového kódu a jednoznačná identifikace toho času aktivního třídicího programu.

io Obr. 6 ukazuje přehled o průběhu kontroly uvnitř Validation Controller pro případ, že tato byla vyvolána čtecím systémem.

V zobrazení jsou k objasnění průběhu uvedené také dodatečně optický záznamový systém (IMM-systém) jakož i AFM-2D čtečka kódu, aby se znázornil celkový kontext kontroly. Podíl šifrovacího systému se však omezuje na to, kontrolovat funkce mezi 2D-čárovým kódem a vrácením jakož i protokolováním výsledku.

V případě rozhraní manažeru zpráv by na Validation Controller startovalo několik Service Tasks, které čekají na zprávy požadavku kontroly a vyvolávaly by obsahem zprávy kontrolní rutinu.

Výsledek kontrolní rutiny se očekává a balí se do zprávy a zasílá se zpět dotazujícímu klientovi.

Na obr. 6 je znázorněno další přednostní provedení řízení průběhu dílčích kontrol pomocí kontrolní jednotky (Validation Controller). U tohoto dalšího přednostního provedení se uskutečňuje zachycení záznamů o frankování pomocí optického záznamového systému (Prima/IMM). Data jsou z optické kontrolní jednotky po čtecí a sběrací jednotkou (AFM-2D čtečka kódu).

U provedení, znázorněného na obr. 6, způsobu ke kontrole platnosti digitálních záznamů o frankování, se uskutečňuje čtení digitálních záznamů o frankování přednostně ještě silnějším automatizovaným způsobem, například optickým záznamem místa poštovní zásilky, na kterém je před3o nostně umístěn záznam o frankování. Další kontrolní kroky se uskutečňují v podstatě podle průběhu kontroly, znázorněného podle obr. 5.

Hodnota vrácení kontrolní rutiny se sestává jednak z kódu zajištění úhrady a příslušného hlášení jakož i obsahu, změněného a rozšířeného o Postage ID. Z těchto hodnot vrácení se vytváří zpráva a předává se na požadovaný čtecí systém.

Obsahové kontroly

2D-obsah čárového kódu rozdělit a přetvořit

Vstup: naskenovaný 2D-čárový kód

Popis:

V této funkci je možné rozdělit obsah 2D-čárového kódu, skládající se z 80 bytů a změnit na strukturovaný objekt, v dalším označený jako objekt 2D-čárový kód, aby se dosáhlo lepší možnosti zobrazení jakož i účinného dodatečného zpracování. Jednotlivá pole a změny jsou popsané v následující tabulce:

Při změně binárních čísel na desítková je třeba dávat pozor na to, že levý byte sledu byte je byte nej vyššího řádu. Pokud se změna nemůže uskutečnit, eventuálně kvůli konfliktu typu nebo chybějícím datům je nutné generovat hlášení příhody zajištění úhrady „PC-F-čárový kód není čitelný“ a vracet ho zpět na „Validation Controller“. Další obsahová, popřípadě šifrovací kontrola, nemá v tomto případě smysl.

-10CZ 301362 B6

pole	typ	změnit na	popis
poštovní podnik	ASCII(3 byte)		není třeba žádná změna
způsob frankování	binární (1 byte}	Smallinteger
identifikační	binární	Smallinteger	Číslo verze
2načka verze	(1 byte)		způsobu
Key-Nr.	binární (1 byte)	Smallinteger	typ kódu
šifrovací řetězec	binární {32 byte)		sled byte je možné převzít beze změny, po dekódování se PostageID rozdělí
Postage ID		text(16 znaků)	vyplní se po dekódování šifrovacího

- 11 CZ 301362 B6

			řetězce
průběžné číslo zásilky	binární {3 byte)	celočíselný	jen kladná čísla
kód produktu	binární (2 byte)	celočíselný	kladná čísla, odkaz na příslušnou referenční tabulku
úhrada	binární (2 byte)	Float	změna na kladné desítkové číslo, které je dělitelné stem, údaj v Euro
datum frankování	binární ¢3 byte)	Dáte	po změně na kladné desítkové číslo se nechá datum změnit podle formátu YYYYMMDD
PSČ příjemce	binární (3 byte)	2 hodnoty, jedna pro zemi, jedna pro kód PSČ	po změně na kladné desítkové číslo poskytují první obě čísla kód země, pět zbývajících číslic PSČ

- 12CZ 301362 B6

ulice/poštovní schránka	ASCII (6 byte)	znak pro ulicí nebo poštovní schránku	pokud se u prvních cifer jedná o čísla, potom je PSČ kódováno, jinak první a poslední tři místa ulice s číslem domu
zbývajíc! obnos poštovného	binární (3 byte)	Float+pole pro měnu (text 32 znaků)	po změně na kladné desítkové číslo dává první cifra měnu (l=Euro), další čtyři cifry místa před desetinnou čárkou a zbývající dvě cifry místa za desetinnou čárkou
transformační hodnota	binární (20 byte)		sled byte je možné přebrat beze změny, slouží k šifrovací validaci

- 13 Cl 301362 B6

frankování

hodnota vrácení: objekt 2D-čárový kód kód výstrahy 00 pokud změna OK, jinak výstraha pro případ zajištění úhrady „PC-F-čárový kód není čitelný“

Kontrola čísla verze

Vstup: aktuální objekt 2D-čárový kód io

Popis:

Z prvních tří polí se nechá rozpoznat verze 2D-čárového kódu. 1 toho se stává také patrným, zda se u záznamu o frankování vůbec jedná o 2D-čárový kód Deutsche Post a ne o 2D-čárový kód jiného poskytovatele služby. Obsahy polí je třeba porovnat se seznamem platných hodnot, předkonfigurováným v aplikaci. Pokud se nenajde žádná shoda, vrací se zpět výstraha zajištění úhrady „PC-F-verze“. Kontrola dalších aspektů, souvisejících s obsahem, ale i šifrovacích, je potom beze smyslu a neměla by se dále sledovat.

Hodnota vrácení: kód výstrahy 00 pokud kontrola verze OK, jinak kód výstrahy pro případ zajištění úhrady „PC-F-verze“

Kontrolovat Postage ID

Vstup: objekt 2D-čárový kód s dekódovaným Postage ID Popis:

Postage ID, obsažené v 2D-čárovém kódu, je zajištěné způsobem kontroly cifer (CRC 16), který je třeba kontrolovat na tomto místě. Pokud by se tato kontrola nezdařila, vrací se zpět jako výsledek výstraha „PC-F podezření na padělání (Postage ID)“. Ke kontrole Postage ID je potřebné předchozí dekódování šifrovacího řetězce.

Hodnota vrácení; kód „00“ pokud je kontrola OK, jinak kód výstrahy pro případ zajištění úhrady „PC-F podezření na padělání (Postage ID)

Kontrola překročení času

Vstup: objekt 2D-čárový kód Popis:

Tato funkce slouží k automatické kontrole intervalu času mezi frankováním PC-frankovanou zásilkou a jejím zpracováním v dopisovém centru. Mezi oběma daty smí ležet jenom určitý počet dní. Počet dní se přitom řídí podle produktu ajeho dobách chodu plus jeden den čekací doba.

Konfigurace časového prostoru se ukládá přednostně v relaci produkt-časové období platnosti a v rámci jedné masce péče se o ní centrálně pečuje. V relaci se ke každému kódu produktu (pole 2D-čárového kódu) možnému pro PC-frankování uchovávají příslušný počet dnů, které smějí ležet mezi frankováním a zpracováním v dopisovém centru. Ve zjednodušeném způsobu se před- 14CZ 301362 B6 konfiguruje jenom údaj časového prostoru, které se vztahují ke standardním zásilkám a jsou jako konstanty uložené v systému.

Ke kontrole se tvoří počet dnů mezi aktuálním datem testu při zpracování a datem obsaženým v 2D-čárovém kódu, například 02.08. až 01.08. = 1 den. Pokud je zjištěný počet dní větší než hodnota pro produkt předem uvedená, vrací se kód zajištění úhrady, přiřazený případu výstrahy „PC-F-Datum (frankování), na Valídation Controller, v jiném případě kód, který dokumentuje úspěšnou kontrolu. Když se ve zjednodušeném způsobu vždy porovnává s hodnotou pro standardní zásilky, měla by být po vydání výsledku kontroly daná možnost, například manuálně přes io tlačítko na skeneru tento výsledek kontroly opravovat, v případě že aktuální produkt připouští delší dobu chodu.

Další kontrola překročení času se vztahuje k obsahu Postage ID. Obnos poštovného, zavedený v rámci daného úkolu, a tím i Postage ID, mají předem dané časové období platnosti, ve kterém je třeba zásilky frankovat. V Postage ID je obsažen časový okamžik, až po který je obnos poštovného platný. Pokud je datum frankování o určitý počet dní větší než toto datum platností, vrací se kód výstrahy zajištění úhrady, patřící k výstraze zajištění úhrady „PC-F-Datum (obnos poštovného)“.

Hodnota vrácení: kód „00“ pokud je kontrola OK, jinak kód výstrahy pro případ zajištění úhrady „PC-F-datum (obnos poštovného)“ nebo „PC-F-Datum (frankování)“

Kontrola úhrady

Vstup: objekt 2D-čárový kód; aktuální třídicí program-ID Popis:

V této funkci se uskutečňuje kontrola úhrady, obsažené v 2D-čárovém kódu, proti minimální úhradě, která je definována pro zásilky příslušného třídicího programu. U obnosů se jedná o obnosy v Euro,

Přiřazení se dodávají přes automatické rozhraní mezi třídicí program a minimální úhradu.

Zjednodušený způsob je možné používat podobně jako při kontrole překročení Času. Zde se v konfiguračním souboru k použití definuje konstantní minimální úhrada, která platí pro všechny zásilky. Proto není zapotřebí předání třídicího programu.

Při následující kontrole se porovnává, zda minimální úhrada, obsažená v 2D-čárovém kódu, leží pod touto značkou. Pokud je tomu tak, vrací se kód, přiřazený případu zajištění úhrady „PC F nedostatečné frankování“, jinak kód úspěchu.

Hodnota vrácení: kód „00“ pokud je kontrola OK, jinak kód výstrahy pro případ zajištění úhrady „PC-F-nedostatečné frankování“

Porovnání s negativním souborem

Vstup: objekt 2D-čárový kód s dekódovaným Postage-ID Popis:

V této funkci se uskutečňuje kontrola, zdaje Postage ID, patřící k 2D-čárovému kódu, obsažené v negativním souboru. Negativní soubory slouží k tomu, aby se zásilky od zákazníků, kteří jsou

-15CZ 301362 B6 vyřazeni kvůli pokusům o zneužití, popřípadě jejichž PC bylo odcizeno, vyňaly z chodu přepravy.

Negativní soubory se přitom udržují centrálně v rámci projektu databáze frankování. V rámci rozhraní k tomuto projektuje třeba stanovit způsob pro výměnu dat na decentralizované systémy dopisového centra.

Pokud eventuálně ještě neexistuje aplikace údržby, popřípadě výměna dat, je třeba zde vytvořit přechodový mechanismus. Údržba těchto dat by se mohla přechodně uskutečňovat v Excello Sheet, ze kterého se generuje csv-soubor. Tento soubor by se měl přes eMail zasílat na AGBzkoušeč a z něho přes navržený importovací mechanismus se načítat do systému. Později se pak uskutečňuje přenos přes cestu, definovanou v přednostním jemném konceptu zajištění úhrady-lT,

Postage IT označuje jediné zadání, které vyvolává zákazník od systému (Postage Point). Tato i s zadání se ukládají v takzvaném Safebox na zákaznickém systému. Jedná se přitom o složku hardware na způsob SmartCard včetně čtecího systému, popřípadě na způsob Dongle. V Safebox se obnosy zadání zabezpečeně ukládají a zákazník z něho může vyvolávat jednotlivé obnosy frankování, aniž by musel být spojen se zaváděcím místem obnosu poplatků.

Každý Safe Box je identifikován jednoznačným ID. Toto Safebox-ID se zanáší do negativního souboru, jestliže se příslušné zásilky mají vyřadit kvůli podezření na zneužití. Safebox-ID je složeno z několika polí. Vedle jednoznačného kódu jsou v Safebox-ID obsažená i další pole jako datum platnosti a kontrolní cifra. K jednoznačnému identifikování Safebox jsou rozhodující první tři pole Safebox-ID. Tyto se opět nacházejí také v prvních třech polích Postage ID, čímž se může uskutečnit přiřazení mezi Safebox a zadáním. Pole jsou popsaná v následující tabulce:

-16CZ 301362 B6

Byte Nr.	délka	význam	obsah dat	komentář
bl	1	identifikace poskytovatele	00	nepoužito
01	test- poskytovatel: podnik zasílající poštu
FF	Postage-Point-Box podniku zasílajícího poštu
b2	1	schválený model Nr.	XX	Pro každého výrobce vzestupně od 01 (první podaný model) obsadit pro každý nově povolený model.
b3,b4, b5	3	sériové číslo modelu	XX XX XX	Pro každý povolený model každého výrobce obsadit vzestupně od 00 00 01 do FF FF FF.

Pokud jsou první tři pole Postage ID aktuálně kontrolovaného frankování identická s prvními třemi poli Safebox-ID, obsažené v negativním souboru, vrací se případ zajištění úhrady, přiřazený v negativním souboru zákazníkovi, jinak kód úspěchu.

Hodnota vrácení: kód „00“ pokud je kontrola OK, jinak zákazníkovi, popřípadě Safe-Box v negativním souboru přiřazený kód výstrahy io Porovnání 2D-obsahu čárového kódu s nešiťrovaným textem zásilky

Vstup: objekt 2D-čárový kód

Popis:

Aby se zabránilo, že se mohou zhotovit kopie z 2D-čárového kódu, provádí se porovnání mezi daty zásilky, kódovanými v 2D-čárovém kódu a daty, uvedenými na dopisu v nešifrovaném textu. Toto porovnání je u radiových skenerů přímo možné, protože tam existují dostatečné mož-17CZ 301362 Bó nosti znázornění a vstupu. U ručních skenerů s napojením dráty je možné provádět kontrolu na PC (systém zajištění úhrady).

Průběh vypadá tak, že Validation Controller po průběhu automatických kontrol zařizuje výdej dat

2D-čárového kódu na radiovém skeneru, popřípadě na PC zajištění úhrady. Zde má k dispozici Calfback-metodu, která se přiřazuje na začátku relace.

Tuto vyvolává aktuálním objektem 2D-Čárový kód. Potom jsou Scanner Controller, popřípadě PC zajištění úhrady, odpovědné za znázornění 2D-obsahu čárového kódu a dodávají zpět jako ío hodnotu vrácení (po zpracování zkoušečem) metodě Callback „00“, popřípadě příslušný chybový kód.

Při úspěšném vyhodnocení se vrací kód úspěchu, jinak kód výstrahy zajištění úhrady „PC-Fnešifrovaný text“.

Při automatické kontrole není tato kontrola zapotřebí. Zde se může kontrola přednostně uskutečnit v rámci centrálních vyhodnocení offline buď pomocí porovnání obratu nebo přes porovnání poštovního směrovacího čísla cíle s poštovním směrovacím číslem obsaženém v 2D-čárovém kódu.

Hodnota vrácení: kód „00“ pokud je kontrola OK, jinak kód výstrahy pro případ zajištění úhrady „PC-F-nešifrovaný text“

Šifrovací kontroly

Šifrovací kontrola se skládá ze dvou částí:

a) dekódování šifrovacího řetězce a 30 b) porovnání transformační hodnoty.

Oba způsoby je třeba provádět v chráněné oblasti šifrovací karty, protože zákazník by při vyslídění informace, vznikající při zpracování, mohl vytvářet platné transformační hodnoty frankování.

Dekódování šifrovacího řetězce

Vstup: objekt 2D-čárový kód 40 Popis:

Jako vstupní parametr obdrží tato funkce rozdělený objekt 2D-čárový kód výsledku skeneru. Na základě data frankování a Key-ěísla se vyhledává symetrický kód platný pro tento časový okamžik a šifrovací řetězec předaného objektu se s pomocí tohoto kódu dekóduje podle způsobu

Triple DES CBC. S jakou hodnotou je třeba inicializační vektor osadit, popřípadě zda se pracuje s Innerbound- nebo Outerbound-CBC a s jakou délkou bloku se pracuje, se rozhoduje v rámci rozhraní k systému zajištění úhrady.

Pokud by neměl kód, obsažený v 2D-čárovém kódu, existovat na šifrovacím systému, tak se výstraha zajištění úhrady „PC-F podezření na padělání (kód)“ vrací s chybovým hlášením, že kód s Key-číslem se nenalezl.

Výsledek operace se skládá z dekódovaného Postage ID, jakož i z dekódovaného náhodného čísla. Dekódovaný Postage ID se zanáší v příslušném poli objektu 2D-čárový kód. Náhodné číslo

- 18CZ 301362 B6 by se z bezpečnostních důvodů nemělo činit známým, protože zákazník by při vlastnictví této informace mohl vytvářet platné transformační hodnoty a tím by mohl padělat 2D-čárové kódy,

V souvislosti s dekódováním se z metody vyvolává výpočet transformační hodnoty a vrací se její 5 hodnota vrácení.

Výpočet transformační hodnoty

Vstup; objekt 2D-čárový kód dekódované náhodné číslo z šifrovacího řetězce (dekódované io náhodné číslo nesmí být známo vně karty)

Popis;

Funkce výpočtu transformační hodnoty zjišťuje z originálního výsledku skeneru, obsaženého i s v objektu 2D~čárový kód, prvních 60 byte. Na to se napojují dekódované Postage ID, jakož i předávaná dekódovaná náhodná čísla. Z toho se vypočítává podle způsobu SHA 1 transformační hodnota a porovnává se s transformační hodnotou 2D-čárového kódu, obsaženou v objektu 2DČárový kód. Pokud se všech 20 byte shoduje, je šifrovací kontrola úspěšná a zpět se vrací příslušná hodnota vrácení.

Při neshodě se na Validation Controller vrací zajištění úhrady-výstraha „PC-F-podezření na padělání (transformační hodnota)“.

Jako hodnota vrácení se dodatečně předává vypočítaná transformační hodnota, aby se tato 25 u výsledku kontroly mohla spoluvydávat.

Hodnota vrácení: vypočítaná transformační hodnota kód „00“ pokud je kontrola OK, jinak kód výstrahy pro případ zajištění úhrady „PC-F-podezření na padělání (transformační hodnota)“ nebo „PC-F-podezření na padělání (kód)“

Výstup výsledku

Znázornit výsledek kontroly a čtení

Popis:

Přes Callback-metodu má Validation Controller možnost, ovládat výstup výsledku na výstupním 40 přístroji, patřícím k aktuální kontrole. K tomu předává této Callback-metodě objekt 2D-čárový kód a zjištěný výstražný kód zajištění úhrady. Jako hodnota vrácení se může poskytovat kód způsobu následného zpracováni, zvolený AGB-zkoušečem.

Callback-metoda pro výstup se, rovněž k začátku relace, při přihlášení přiřazuje na Validation 45 Controller.

Zaprotokolování výsledku

Vstup; objekt 2D-čárový kód, kód výsledku kontroly

Popis:

Zaprotokolování výsledku se uskutečňuje zjednodušeným způsobem v souboru na systému, na kterém běží Validation Controller. Zpravidla se výsledky, popřípadě sady oprav, předávají přímo

- 19CZ 301362 B6 na BDE a přes přednostní zajištění úhrady-BDE-rozhraní se zapisuji do databáze přednostního lokálního systému zajištění úhrady.

Přednostně se ukládají Postage ID, pořadové číslo, datum frankování, úhrada, kód produktu,

PSČ, zajištění úhrady-kód výsledku, text hlášení, doba kontroly, Časový okamžik kontroly, ID skeneru, režim skeneru, modus záznamu, jakož i způsob dalšího zpracování. Všechny hodnoty, od sebe oddělené pomocí středníku, se vydávají v právě jedné větě na zásilku a nechají se tak například vyhodnocovat v Excel.

Pokud se systém nachází v režimu „první záznam, je třeba ve sloupci modus záznam uvést „e“ místo ,.n” pro dodatečné zjišťování.

Vyhledávání kmenových dat

Popis:

Pro obsahovou kontrolu je nutná řada kmenových dat. Přitom se jedná o:

PC-F-negativní soubor · třídicí programy a minimální úhrady • všeobecná nej menší úhrada • kód produktu PC-F • maximální doba doručení na kód produktu PC-F • všeobecná maximální doba doručení · případy zajištění úhrady, priority a přiřazení k příkazům dalšího zpracování • příkazy dalšího zpracování

Kmenová data se mohou pevně předem konfigurovat v přechodovém čase s výjimkou PC-Fnegativního souboru jakož i šifrovacího kódu zaváděcího místa obnosu poplatku (Postage Point).

Pokud je to nutné, mohou se pro část dat implementovat jednoduché aplikace zpracování a rozdělování, Péče by se potom měla uskutečňovat v Excel-Sheet, ze kterého se generuje csv-soubor. Tento soubor by se měl zasílat přes eMail na AGB-zkouŠeě a od něho se přes navrhovaný mechanismus načítá do systémů.

Data se zpravidla rozdělují podle způsobu, popsaného v přednostním jemném konceptu zajištění úhrady-ΙΤ, popřípadě se umožňuje přístup na tato data.

Příslušné datové struktury se popisují v datovém modelu k jemnému konceptu přednostního zajištění úhrady.

Rozdělení dat kódů

Symetrické kódy, které na zaváděcím místě obnosu poplatku (Postage Point) slouží k zajištění

2D-obsahů čárového kódu a které potřebují šifrovací systém k validaci, se z bezpečnostních důvodů vyměňují v pravidelných odstupech. Pri použití ve všech dopisových centrech se kódy musí přenášet od (Postage Point) k šifrovacím systémům automaticky a zabezpečeně.

Výměna by se měla přitom uskutečňovat přes přednostní server zajištění úhrady, protože u zavá50 děcího místa obnosu poplatku (Postage Point) by se nemělo konfigurovat, které přednostní lokální systémy zajištění úhrady a které šifrovací systémy k tomu existují.

-20CZ 301362 B6

Zvláště přednostní kroky způsobu pro výměnu kódů jsou znázorněné na obr. 7. Přednostní výměna kódů se uskutečňuje mezi centrálním místem zavádění (Postage Point), centrálním šifrovacím serverem a několika lokálními šifrovacími servery.

Protože symetrické kódy mají velký význam pro zabezpečení proti padělání 2D-ěárového kódu, musí být výměna zajištěna pomocí silného šifrování a pomocí jednoznačné autentifikace partnerů pro komunikaci.

Konfigurace

Základní konfigurace/Key Management šifrovacího hardware

Pro základní konfiguraci šifrovací karty jsou nutná různá opatření. Měla by se provádět prostřednictvím bezpečnostního administrátora. Jedná se přitom přibližně o následující činnosti:

• instalace software-API na kartě • generování, popřípadě instalace privátních kódů k zajištění administrativních aplikací a nahrávaného software

Podle zvoleného typu karty a výrobce karty jsou přitom nutná rozdílná opatření.

Na aplikaci vztažená základní konfigurace šifrovací karty, navržená pro přednostní systém zajištění úhrady, se skládá z následujících kroků:

• zabezpečené kódování a přenos symetrických kódů na kartu - například RSA-kód-pár - při současném vytváření certifikátu pro Public Key a vydání Key • certifikát zaváděcího místa obnosu poplatku (Postage Point) pevně předem konfigurovat k zajištění, že kód, který je třeba importovat, byl vystaven zaváděcím místem obnosu poplatku (Postage Point).

Základní konfigurace aplikace šifrovacího systému

Každý skener, každý uživatel a každá šifrovací karta uvnitř šifrovacího systému musí být charakterizovány pomocí jednoznačného ID. Naposled je také nutné každou AFM-2D čtečku kódu identifikovat pomocí jednoznačného ID.

Login/Logoff

Na začátku každé relace s Validation Controller se musí uskutečnit Login. Toto Login obsahuje jako parametr skener-ID, User ID jakož i Callback-metody pro manuální kontrolu, popřípadě výstup výsledků čtení a kontroly.

Jako hodnota vrácení se vrací zpět Session-ID, které se u následujících kontrolních zavolání může spolu předávat uvnitř relace. K Session-ID se na Validation Controller ukládá Session C on text, ve kterém se ukládají parametry přesunu.

Pokud uživatel během své relace provádí změny na druhu práce, na předdefinovaném produktu, popřípadě na dalších nastaveních relace, konfigurovatelných k době chodu, tyto změny se sledují v k tomu přirazených proměnných uvnitř Session Context.

Při LogofT se Session Context příslušně maže. Následující vyvolání kontroly s tímto Session ID se odmítají.

-21 CZ 301362 B6

Správu uživatelů a hesel je třeba definovat ve všeobecném konceptu správy uživatelů pro přednostní zajištění úhrady, součástí jemného konceptu je přednostní zajištění úhrady-IT.

Čtenářské systémy se musí před prováděním dotazů na kontrolu nechat registrovat u Validation

Controller. Jako parametr je třeba předávat ID čtecího systému jakož i heslo. Jako hodnota vrácení se při úspěšném přihlášení rovněž vrací zpět Session ID, které je třeba předávat při následujících požadavcích na kontrolu.

Při Shutdown čtecího systému se musí uskutečňovat příslušný Logoff s tímto Session ID.

Ostatní

Speciální úlohy uživatele

V rámci bezpečnostního konceptu je třeba navrhovat dvě speciální úlohy uživatele, které je třeba vyplňovat dvěma různými osobami.

Bezpečnostní administrátor (administrátorka)

2o Úloha bezpečnostního administrování zahrnuje následující úkoly:

• zhotovení souborů příkazů k administrování šifrovací karty • signování těchto souborů příkazů • inicializováni a správa šifrovacích karet · kontrola nahrávaného software a příslušné konfigurace

Bezpečnostní administrátor se autentifikuje Přiváté Key na administrování karet. Tento je uložen na disketě nebo Smart Card a musí se bezpečnostním administrátorem držet přísně pod zámkem.

Jenom tímto kódem signované příkazy administrováni příkazy se nechají provádět na šifrovací kartě. Protože tímto mechanismem jsou chráněné sekvence příkazů a příslušné parametry, může se provádění těchto příkazů také delegovat na systémové administrátory na místě. Bezpečnostní administrátor musí k tomu dát k dispozici příkazy a psát příslušnou instrukci proceduiy.

Další úkol spočívá ve správě šifrovacích karet, přičemž ke každé kartě se udržuje sériové číslo, konfigurace a systémové číslo systému, ve kterém jsou tyto instalovány, jakož i stanoviště systému. U rezervních šifrovacích karet se dále udržuje, v koho vlastnictví se karty nacházejí.

Spolu s manažerem bezpečnosti QS kontroluje softwarové zdroje a příslušnou konfiguraci software a uvolňuje je k instalaci.

Mimoto se uskutečňuje kontrola software, který je třeba instalovat na šifrovacím serveru, popřípadě je instalován, jakož i uvolnění a signování software karty.

Software karty je třeba potom speciálně kontrolovat, zda na nějakém místě se jeden z tajných kódů může vydávat přes rozhraní ovládače ven, popřípadě zda tam byly prováděny pokusy o manipulaci jako například ukládání konstantních předdefinovaných kódů nebo používání nespolehlivých způsobů kódování. Dodatečně k software karty je také možné kontrolovat s ním spojený aplikační software šifrovacího serveru.

Autentifíkace se uskutečňuje právě tak jako u bezpečnostního administrátora s Private Key, Přitom se jedná ale o Private Key k signování software.

-22CZ 301362 B6

Existuje zde ale dodatečné zabezpečení v tom, že k instalaci software není třeba signovat jenom software, nýbrž také příslušný instalační příkaz. Protože k tomu jsou příslušné dvě různé osoby (manažer QS a bezpečnostní administrátor) a tím, že příslušné kódy se uchovávají na dvou různých místech, je zde rovněž zaručeno vysoké zabezpečení.

Distribuce software se provádí manažerem zabezpečení QS v souladu s bezpečnostním administrátorem.

Toto zvláště přednostní provedení vynálezu tím navrhuje dva různé autentifíkační kódy, takže io zabezpečení dat se značně zvyšuje.

Claims

15 PATENTOVÉ NÁROKY

1. Způsob ke kontrole pravosti záznamu o frankování, umístěného na poštovní zásilce, přičemž v záznamu o frankování obsažená šifrovací informace se používá dekódovaná a ke kontrole

20 pravostí záznamu o frankování, vyznačující se tím, že kontrolní jednotka řídí průběh dílčích kontrol, přičemž první dílčí kontrola obsahuje přečtení maticového kódu, obsaženého v digitálním záznamu o frankování, že kontrolní jednotka řídí rozdělení obsahu maticového kódu, že dílčí kontroly se uskutečňují jako kroky kontroly, že kontrolní jednotka současně může provádět několik kontrolních dotazů jakož i může paralelně k tomu provádět část kontrolních kroků, že

25 pomocí kontrolních kroků se zjišťují neoprávněně vytvořené záznamy o frankování, že výsledek kontroly se přenáší jako digitální zpráva a že se tím vyřazuje zásilka z normálního chodu zpracování poštovních zásilek.

2. Způsob podle nároku 1, vyznačující se tím, že jedna z dílčích kontrol obsahuje

30 dekódování šifrovacích informací, obsažené v záznamu o frankování.

3. Způsob podle jednoho nebo více z nároků 1 nebo 2, v y z n a č u j í c í se t í m, že jedna z dílčích kontrol obsahuje porovnání mezi datem vytvoření záznamu o frankování a aktuálním datem.

4. Způsob podle jednoho nebo více z předcházejících nároků, vyznačující se tím, že čtecí jednotka a kontrolní jednotka si vyměňují informace pomocí synchronního protokolu.

5. Způsob podle nároku 4, vyznačující se tím, že protokol je založen na RPC.

6. Způsob podle jednoho nebo více z nároků laž5, vyznačující se tím, že čtecí jednotka a kontrolní jednotka spolu komunikují přes asynchronní protokol.

7. Způsob podle nároku 6, vyznačující se tím, že čtecí jednotka vysílá datovou

45 zprávu na kontrolní jednotku.

8. Způsob podle nároku 7, vyznačující se tím, že datová zpráva obsahuje obsah záznamu o frankování.

50

9. Způsob podle jednoho nebo více z nároků 1 až 8, vyznačující se tím,že datový telegram obsahuje požadavek ke startu Šifrovací kontrolní rutiny.

10. Způsob podle jednoho nebo více z nároků 1 až 9, vyznačující se tím, že pomocí šifrovací interface se uskutečňuje rovnoměrné vytížení mezi několika kontrolními prostředky.

-23CZ 301362 B6

11. Způsob podle jednoho nebo více z nároků 1 až 10, vyznačující se tím, že obsah záznamu o frankování se rozděluje na jednotlivá pole.

12. Způsob podle jednoho nebo více z předcházejících nároků, vyznačující se tím,

5 že identifikační číslo (Postage ID) zákaznického systému řídicího vytváření záznamu o frankování se zjišťuje ze záznamu o frankování.

13. Způsob podle jednoho nebo více z předcházejících nároků, vyznačující se tím, že jednotlivé údaje identifikace zákaznického systému (Postage ID) se zachycují v negativním io souboru a zásilky patricí k tomuto Postage ID se vyřazují z normálního průběhu zpracování poštovních zásilek.

14. Způsob podle jednoho nebo více z předcházejících nároků, vyznačující se tím, že zakódovaný údaj o adrese příjemce obsazený v záznamu o frankování se porovnává s adresou příjemce, uvedenou pro doručování poštovní zásilky.

15. Způsob podle jednoho nebo více z nároků 1 až 14, vyznačující se tím, že kontrolní parametry způsobu se mohou měnit.

20 16. Způsob podle nároku 15, vyznačující se tím, že změna parametrů způsobu se uskutečňuje jenom po zadání osobního digitálního kódu (Private Key) systémového administrátora.