CREO: Was öffentlich belegt ist – und was nicht
Eine technische Verbraucherwarnung zu den öffentlich kommunizierten Sicherheits-, Produkt- und Crowdfunding-Claims von CREO. Ziel ist nicht, Betrug zu behaupten, sondern außergewöhnliche Versprechen an überprüfbaren technischen Standards zu messen.
Executive Summary
Urteil
Methodik & Fairness
Dieses Review trennt drei Ebenen strikt:
QUELLENFAKT Was CREO oder ein Plattform-/Standardhersteller selbst öffentlich dokumentiert.
TECHNISCHE EINORDNUNG Schlussfolgerung aus mehreren Primärquellen.
NICHT BELEGT Ein für die Aussage erforderlicher Nachweis wurde in den geprüften öffentlichen Unterlagen nicht gefunden.
Identität sauber trennen
Das CREO-Impressum nennt Danny Avit Carel als Vertreter der CREO Solutions UG. Die öffentlich auffindbare Aussage zur Ausführung „unter dem OS“ stammt dagegen aus einem CREO-bezogenen Beitrag des Accounts @mr.xennt. Deshalb wird diese Aussage hier nicht ungeprüft als „CEO-Aussage“ bezeichnet.
1. Claim: CREO läuft „unter dem Betriebssystem“
„Dieser Container läuft nicht auf das OS, das läuft unter das OS … Das OS hat kein Zugriff auf CREO.“Öffentlich auffindbarer Instagram-Reel, CREO-bezogener Account. Die Formulierung wird hier als Produktclaim geprüft, nicht als Beweis der technischen Umsetzung.
Warum das technisch entscheidend ist
Eine normale iOS- oder Android-App läuft nicht automatisch in einer Vertrauensschicht unterhalb des Betriebssystems. Android beschreibt seine App-Isolation als kernel-level Application Sandbox; Apple dokumentiert für iPhone/iPad, dass Drittanbieter-Apps sandboxed sind und privilegierte Zugriffe über vom System bereitgestellte Dienste und Entitlements erfolgen.
Das CREO-Whitepaper beschreibt gleichzeitig einen gewöhnlichen Installationsweg für Windows, macOS, Linux, Android und iOS. Daraus folgt eine zentrale offene Frage: Welche konkrete Plattform-/Firmware-/Hypervisor-Integration verschiebt CREO auf einem unveränderten Smartphone tatsächlich aus der Kontrolle des OS?
Auf einem handelsüblichen, unveränderten iPhone oder Android-Gerät: Welche konkrete Trust Boundary, Firmware-Komponente, Hardware-Funktion und Attestation beweisen, dass ein kompromittierter OS-Kernel keinen Zugriff auf die CREO-Runtime hat?
2. Whitepaper-Claim: Schutz selbst vor kompromittierten OS-Komponenten
QUELLENFAKT CREOs Whitepaper v4.8 beschreibt eine „Protected runtime“, die Malware, Rootkits und kompromittierte Betriebssystemkomponenten vom Datenzugriff abhalten soll.
Was die genannten Technologien tatsächlich sind
Technische Einordnung
TECHNISCHE EINORDNUNG Diese Technologien zeigen, dass Ausführung außerhalb der normalen OS-Vertrauensdomäne grundsätzlich möglich ist. Sie beweisen jedoch nicht, dass eine regulär installierte CREO-App auf jedem unterstützten iOS-/Android-Gerät genau so ausgeführt wird. Dafür fehlt in den geprüften Unterlagen eine plattformspezifische Integrations- und Attestationskette.
NICHT BELEGT Eine öffentlich nachvollziehbare Demonstration eines kompromittierten Smartphone-Kernels gegen eine laufende CREO-Session wurde in dieser Prüfung nicht gefunden.
3. „AES-512“: proprietär, nicht standardisiertes AES
CREO bezeichnet „AES-512“ im Whitepaper ausdrücklich als eigene kryptografische Konstruktion außerhalb der NIST-standardisierten AES-Familie und kündigt unabhängige Kryptografie-Audits für die Zeit vor dem Produktionsrelease an.
Der NIST-Standard FIPS 197 spezifiziert AES mit 128-, 192- und 256-Bit-Schlüsseln sowie 128-Bit-Blöcken.
Warum „mehr Bits“ kein Sicherheitsbeweis ist
TECHNISCHE EINORDNUNG Bei einer proprietären Blockchiffre ist die Schlüssellänge nur ein Teil der Sicherheitsfrage. Entscheidend sind Konstruktion, Kryptoanalyse, Implementierung, Side-Channel-Verhalten, Schlüsselableitung, Protokollintegration und unabhängige Prüfung. Ein größerer nomineller Schlüsselraum ersetzt diese Nachweise nicht.
NICHT BELEGT In den geprüften offiziellen CREO-Unterlagen verweist CREO selbst auf zukünftige unabhängige Audits. Ein veröffentlichter externer Kryptografie-Audit für diese proprietäre Konstruktion wurde in dieser Prüfung nicht gefunden.
4. Produktreife, Vorauszahlung und Token-Kommunikation
Bewertung
TECHNISCHE / VERBRAUCHER-EINORDNUNG Das ist zunächst eine Kommunikations- und Risikokonsistenzfrage, keine von uns vorgenommene rechtliche Klassifikation. Wer heute Geld zahlt, trägt Produkt-, Ausführungs- und Token-Risiken für Leistungen, die laut Website erst zukünftig verfügbar sein sollen.
Besonders wichtig: Der auf der Website angezeigte Entwicklungswert von 0 % wird hier nur als angezeigter Webseitenstatus dokumentiert. Daraus wird nicht abgeleitet, dass intern keinerlei Entwicklung stattgefunden hat.
5. Produktkonsistenz: Plugin-Store vs. „Zero-Skill“-Philosophie
Die CREO-FAQ und das Whitepaper beschreiben einen Plugin-Store und konkrete Plugin-Funktionen. Ein aktueller CREO-Blogbeitrag sagt dagegen:
„Bei CREO haben wir uns gegen Plugins, Skills und Extensions entschieden.“
TECHNISCHE EINORDNUNG Eine Roadmap darf sich ändern. Problematisch wird es nur, wenn bereits verkaufte oder beworbene Leistungsversprechen davon betroffen sind und die Änderung nicht eindeutig reconciled wird. Für Käufer sollte klar dokumentiert sein, welche Version der Produkt- und Token-Roadmap aktuell verbindlich gemeint ist.
6. Was gegen einen vorschnellen „Scam“-Claim spricht
Diese Punkte sind relevant, weil sie gegen die einfache Behauptung sprechen, es handle sich bloß um eine anonyme Fake-Webseite. Sie widerlegen jedoch nicht die separaten Fragen nach technischer Realisierbarkeit, Produktreife oder wirtschaftlichem Risiko.
Risikomatrix für Verbraucher
| Bereich | Befund | Risiko | Was vor Vertrauen fehlen würde |
|---|---|---|---|
| „Unter dem OS“ / kompromittierter Kernel | Außergewöhnlich starker Claim; Plattformintegration öffentlich nicht ausreichend gezeigt | HOCH | Plattformspezifische Architektur, Attestation, adversarialer Nachweis |
| Proprietäre „AES-512“-Konstruktion | CREO selbst klassifiziert sie als proprietär; Audit wird für vor Release angekündigt | HOCH | Unabhängige Kryptografie-Audits + reproduzierbare Binary-Bindung |
| Produktreife vs. Marketing | Sehr starke Sicherheitswerbung bei noch zukünftiger Produktverfügbarkeit | HOCH | Öffentlich testbarer Build + reproduzierbare Security-Demos |
| Vorauszahlung / zukünftige Leistung | 100 € heute gegen zukünftige Codes und Tokens | HOCH | Klare Leistungs-, Rückabwicklungs- und Risikobedingungen |
| Token-/Investment-Sprache | FAQ und Whitepaper verwenden unterschiedliche Einordnungen | MITTEL–HOCH | Konsistente, juristisch geprüfte Verbraucherinformation |
| Anbieteridentität | Impressum und Registerangaben öffentlich vorhanden | NIEDRIGER | Kein zentraler Identitäts-Red-Flag in dieser Prüfung |
Was CREO vor einer belastbaren Vertrauensaussage belegen müsste
- Reproduzierbare, öffentlich testbare Builds für die tatsächlich beworbenen Plattformen.
- Plattformspezifische Runtime-Architektur mit Trust Boundaries für iOS, Android, Windows, macOS und Linux.
- Attestation bzw. Messkette, die beweist, wo CREO gegenüber Kernel, Hypervisor, Firmware und TEE/Realm tatsächlich läuft.
- Adversarialer Demonstrationstest: kompromittierter OS-Kernel gegen eine laufende CREO-Session.
- Unabhängige Kryptografie- und Implementierungs-Audits der proprietären Konstruktionen – nicht nur interner Review.
- Reproduzierbare Build-Hashes, die veröffentlichte Audits kryptografisch an ausgelieferte Binaries binden.
- Konsistente Produkt- und Crowdfunding-Dokumentation, insbesondere zu Plugins, Aktivierungscodes, Token-Rechten, Handelbarkeit und Rückerstattung.
Je außergewöhnlicher der Claim, desto stärker muss der Nachweis sein. Bei einem Sicherheitsprodukt genügt „proprietär“ nicht als Ersatz für unabhängige Verifikation.
Veröffentlichungsfähige Verbraucherwarnung
Technischer Warnhinweis zu CREO
Ich rate derzeit davon ab, CREO aufgrund seiner außergewöhnlichen Sicherheitsversprechen ungeprüft zu vertrauen oder für zukünftige Leistungen Geld vorauszuzahlen.
CREO bewirbt ein noch nicht veröffentlichtes Produkt mit sehr weitreichenden Claims – darunter Schutz gegenüber kompromittierten Betriebssystemkomponenten und eine proprietäre, als „AES-512“ bezeichnete Kryptografie. Die öffentlich verfügbaren Unterlagen zeigen bislang nicht die unabhängigen Nachweise, die solche Aussagen aus meiner Sicht benötigen.
Besonders klärungsbedürftig ist die Behauptung, CREO laufe auf Smartphones in einer Schicht, auf die das Betriebssystem keinen Zugriff habe. Für eine regulär installierte iOS-/Android-App müsste CREO dafür die konkrete Hardware-, Firmware- und Trust-Boundary-Architektur sowie unabhängige Angriffstests offenlegen.
Auch die Crowdfunding-Kommunikation sollte eindeutig reconciled werden: Auf der offiziellen Seite werden heute gegen 100 € zukünftige Aktivierungscodes und Governance-Tokens angeboten; verschiedene CREO-Unterlagen verwenden dabei unterschiedliche Investment- und Produktformulierungen.
Das ist keine Behauptung, CREO sei ein Scam oder Exit Scam. Es ist eine Warnung vor derzeit nicht ausreichend öffentlich verifizierten Security- und Produktclaims. Mein Maßstab ist einfach: Erst unabhängige technische Beweise, dann Vertrauen und Geld.
Quellen & Evidenz
- CREO Solutions – deutsche Startseite · Produktclaim, Entwicklungsanzeige, Crowdfunding-Angebot · Abruf 09.08.2026.
- CREO Solutions – Impressum · Anbieterangaben / Vertretung · Abruf 09.08.2026.
- CREO FAQ · Crowdfunding-, Investment-, Token-, Refund- und Plugin-Aussagen · Abruf 09.08.2026.
- CREO Whitepaper v4.8 · Encrypted Execution, proprietäre Kryptografie, Installation, Tokenomics, Disclaimer · Abruf 09.08.2026.
- @mr.xennt – öffentliches CREO-bezogenes Reel · „unter dem OS“-Claim · über Websuche verifiziert 09.08.2026.
- CREO Blog – Zero-Skill-Philosophie · Aussage gegen Plugins/Skills/Extensions · Abruf 09.08.2026.
- NIST FIPS 197 – Advanced Encryption Standard · Standardisierte AES-Varianten.
- Android Open Source Project – Application Sandbox · Kernel-Level-App-Isolation.
- Apple Platform Security – Security of runtime process · Sandboxing von Drittanbieter-Apps.
- AMD – Secure Encrypted Virtualization · VM-basierte Confidential-Computing-Technik.
- Intel – Trust Domain Extensions · Hardware-isolierte Trust-Domain-VMs.
- Arm – Confidential Compute Architecture · Realms und Isolation vom Normal-World-Kernel/Hypervisor.
Reproduzierbarkeit
Lokale SHA-256-Fingerprints der für Screenshot-Belege verwendeten PDFs:
CREO Whitepaper v4.8: 7b9769e2f10eda6240d420111c57fa64374121ae2dea6c47a22920b459aa22e7
NIST FIPS 197: 89c6da9e6cb81ffb7c115752b789ff3dc205acb2b13d6a36ff55acc79e87f61e
Hinweis: Webseiten können sich nach dem Analysestand ändern. Aussagen im Review beziehen sich auf den dokumentierten Abrufstand.